Re: Wrong routing when combining ip rule with SNAT

[Vigneswaran R <vignesh@atc.tcs.com>]

On 09/17/2013 06:28 AM, Nikolaus Rath wrote:
> Hi Eliezer,
>
> I have a VPN connection, and I want to tunnel everything through the VPN
> node -- except, of course, the VPN connection itself.
>
> The hard part is to also tunnel non-VPN connections to the VPN node
> itself. In other words how do I make sure that every connection to the
> external ip of the VPN node is tunneled through its internal ip --
> except for the packets that form the tunnel itself?
>
> My idea was install a default route to the internal ip of the VPN node,
> use iptables to mark the VPN connections and then set up a special
> routing table for those. But maybe there's an easier way?

* What is the internal IP of the VPN node? Is it 192.168.12.1 (and ebox 
is the VPN node)?

* How the nodes are connected? Is it something like,

    vostro <---> ebox <---> [Internet]

If so, where is 192.168.17.1 located.


Regards,
Vignesh
>
> Best,
> Nikolaus
>
> Eliezer Croitoru <eliezer@ngtech.co.il> writes:
>> Hey there,
>>
>> What are you trying to achieve exactly?
>> I tried to understand the network topology and the network issues but
>> since you did not marked a target to what you want to actually get.
>> There is an option to actually understand the situation you are in by
>> just describing the need and the situation and then continue from there.
>>
>> Hope for the best
>> Eliezer
>>
>> On 09/13/2013 08:10 AM, Nikolaus Rath wrote:
>>> Hello,
>>>
>>> Thanks for working on this great networking stack!
>>>
>>> I'm trying to set up a configuration with SNAT and routing rules, but
>>> I'm having weird problems that I do not understand:
>>>
>>> I've enabled packet forwarding and SNAT on the "ebox" computer as
>>> follows:
>>>
>>> root@ebox:~# ip route
>>> default via 23.92.25.1 dev eth0
>>> 23.92.25.0/24 dev eth0  proto kernel  scope link  src 23.92.25.96
>>> 192.168.12.0/24 dev rath  proto kernel  scope link  src 192.168.12.1
>>>
>>> root@ebox:~# iptables  -L -n -v
>>> Chain INPUT (policy ACCEPT 1314 packets, 1736K bytes)
>>>   pkts bytes target     prot opt in     out     source               destination
>>>
>>> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>>>   pkts bytes target     prot opt in     out     source               destination
>>>   150K   62M ACCEPT     all  --  rath   eth0    0.0.0.0/0            0.0.0.0/0
>>> 86746  200M ACCEPT     all  --  eth0   rath    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
>>>    319 22076 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 1/min burst 30 LOG flags 0 level 4 prefix "Rejected forwarding: "
>>>    393 26172 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-net-prohibited
>>>
>>> Chain OUTPUT (policy ACCEPT 1142 packets, 2412K bytes)
>>>   pkts bytes target     prot opt in     out     source destination
>>>   
>>> root@ebox:~# iptables -t nat -L -n -v
>>> Chain PREROUTING (policy ACCEPT 36378 packets, 2383K bytes)
>>>
>>> Chain INPUT (policy ACCEPT 19982 packets, 1334K bytes)
>>>   pkts bytes target     prot opt in     out     source               destination
>>>
>>> Chain OUTPUT (policy ACCEPT 61430 packets, 4601K bytes)
>>>   pkts bytes target     prot opt in     out     source               destination
>>>
>>> Chain POSTROUTING (policy ACCEPT 8333 packets, 564K bytes)
>>>   pkts bytes target     prot opt in     out     source               destination
>>> 69488 5081K SNAT       all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            to:23.92.25.96
>>>
>>>     
>>>  From a second computer "vostro", I can now use ebox as a gateway:
>>>
>>> root@vostro:~# ip route add 190.93.249.164 via 192.168.12.1
>>>
>>> This works fine, now connections to whatismyip.com (190.93.249.164) go
>>> through ebox.
>>>
>>> However, when I try to be a bit more selective on vostro and use a
>>> special routing table, things don't work anymore:
>>>
>>> root@vostro:~# iptables -t mangle -L -n
>>> Chain PREROUTING (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> Chain INPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> Chain FORWARD (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>> MARK       tcp  --  0.0.0.0/0            190.93.249.164       tcp dpt:80 MARK set 0x1
>>> LOG        tcp  --  0.0.0.0/0            190.93.249.164       tcp dpt:80 LOG flags 0 level 4 prefix "marked: "
>>>
>>> Chain POSTROUTING (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> root@vostro:~# ip route del 190.93.249.164 via 192.168.12.1
>>> root@vostro:~# ip route add default via 192.168.12.1 table tovpn
>>> root@vostro:~# ip rule add fwmark 0x1 table tovpn
>>>
>>> Now connections from vostro to 190.93.249.164 still make it to ebox, and
>>> from ebox to 190.93.249.164, but the answers get stuck on ebox:
>>>
>>> Sep 13 04:47:53 ebox kernel: Rejected forwarding: IN=eth0 OUT=eth0 MAC=f2:3c:91:69:db:07:84:78:ac:0d:79:c1:08:00 SRC=190.93.249.164 DST=192.168.17.47 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=0 DF PROTO=TCP SPT=80 DPT=39024 WINDOW=14480 RES=0x00 ACK SYN URGP=0
>>>
>>> It seems that ebox tries to send the packet destined to go trough the
>>> rath to eth0 instead, and consequency rejects them because forwarding is
>>> only enabled from eth0 to rath.
>>>
>>> However, this only happens when vostro has the gateway route set in a
>>> special routing table rather than the default table -- but how does ebox
>>> even know about that?
>>>
>>> Can someone explain to me what is happening here and why?
>>>
>>>
>>>
>>> Best,
>>>
>>>     -Nikolaus
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>     -Nikolaus
>