[strongSwan] Why doesn't table 220 change forwarded packets source IP address?

[Richard Chan]

My scenario is  VMs behind the roadwarrior(carol) reaching gateway(moon)'s
subnets (alice).

1. carol to moon subnets - this works correctly as a point2site network.

2. carol - has a KVM libvirt 192.168.122.0/24  network totally unknown to
moon. I want these VMs to reach the subnets behind moon by carol being a
VPN/NAT. To my surprise:

a. this works by SNAT of 192.168.122.x in POSTROUTING to carol's leftip

b. why is this surprising: I thought table 220 would intercept these
packets as well ("from all"), change the source to leftip, no connection
tracking,  and therefore the return packets would fail.

However, what happened was that packets from 192.168.122.0/24 to moon,
skipped table 220, giving me a chance to SNAT in POSTROUTING and it works!

3. Now ip rule 220 looks like a "from all" rule so I'm  curious why didn't
 forwarded packets from carol libvirt 192.168.122.0/24 didn't get affected
by the policy.

I.e.

192.168.122.2 (VM) --- carol(roadwarrior, leftip=10.1.1.1) ----
moon(gateway) --- alice 10.1.2.1

* carol can reach alice
* moon: does not know about 192.168.122.0/24

Expected: 192.168.122.2 to 10.1.2.1 to fail because 192.168.122.0/24 would
be "ip rule 220"-ed and changed to 10.1.1.1, and carol has no connection
tracking for this packet.

Observed:  192.168.122.x to 10.1.2.1, skips table 220, reaches POSTROUTING,
and can be SNAT
 to 10.1.1.1 (and everything works).

Sorry, if I was not clear earlier. I meant, I didn't expect subnets behind
the roadwarrior to be able to make it moon.



On Sun, Nov 6, 2016 at 10:10 PM, Andreas Steffen <
andreas.steffen at strongswan.org> wrote:

> Hi Richard,
>
> the table 220 source IP routing rule applies to packets originating
> from the VPN gateway itself, only . If you want roadwarriors from a
> subnet behind the GW to assume this address then you have to NAT them
> to the GW's address. Since the table 220 rule usually maps the GW's
> source address to the local interface on the subnet I don't see
> the sense of the roadwarriors belonging to this subnet to assume
> the gateway's internal address.
>
> Regards
>
> Andreas
>
> On 05.11.2016 18:01, Richard Chan wrote:
>
>> Hi, in the roadwarrior configuration, from a conceptual point of view,
>> why doesn't table 220 change the source IP address of forwarded packets
>> (say the roadwarrior has a subnet behind it)?
>>
>> # ip ro sho table 220
>> 10.0.0.0/8 <http://10.0.0.0/8> via 192.168.1.1 dev eth0  proto static
>>   src 10.2.0.3
>>
>> # ip rule show
>> 0:      from all lookup local
>> 220:    from all lookup 220
>> 32766:  from all lookup main
>> 32767:  from all lookup default
>>
>> roadwarrior has a separate subnet 192.168.2.0/24 <http://192.168.2.0/24>
>> and is forwarding/NAT'ing packets.  When  I ping a host on the central
>> site LAN
>>
>> - OUTPUT chain sees the source IP address as 10.2.0.3 (table 220 is
>> working!)
>> -  FORWARD chain sees the source IP address as 192.168.2.X  (host cannot
>> be reached until these packets are SNAT'ed to 10.2.0.3)
>>
>>
> Richard Chan
>>
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Open Source VPN Solution!          www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
>


-- 
Richard Chan
Chief Architect

TreeBox Solutions Pte Ltd
1 Commonwealth Lane #03-01
Singapore 149544
Tel: 6570 3725
http://www.treeboxsolutions.com

Co.Reg.No. 201100585R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20161107/551083a6/attachment.html>