[strongSwan] roadwarrior as gateway, possible?

Fri Dec 26 15:56:48 CET 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello Zesen,

I cannot send mail to me at riaqn.com.

Okay, so NAT happens in *nat POSTROUTING (nat table, POSTROUTING chain).
So all rules pertaining NAT are in that chain.
NAT is implemented using the MASQUERADE and SNAT targets.
Example rules for NAT are those:
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A POSTROUTING -J SNAT

In most installations, NAT is only wanted for traffic from the LAN to WAN,
so the rules mostly look like that:
iptables -t nat -A POSTROUTING -o wan -j MASQUERADE
Here, "wan" is the interface to the WAN.

Because IPsec on Linux is policy based and transparently implemented
(there are no interfaces for IPsec), that rule matches traffic, that goes into a tunnel, too.
So you must except it from nat. Follow the packet flow graph at [1].

The "policy" match module of iptables enables you to search for an IPsec policy that
matches the packet. That means, that you can build rules that match on traffic with or without
an IPsec policy.

For example, this rule masquerades all traffic going out of eth0 and not having an IPsec policy:

iptables -t nat -A POSTROUTING -o eth0 -m policy --pol none --dir out -j MASQUERADE

Read the man page for the iptables extensions for a description of all match modules and targets
in iptables. Mostly, that page is called "iptables-extensions".

[1] inai.de/images/nf-packet-flow.png

Mit freundlichen Grüßen/Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 26.12.2014 um 14:47 schrieb Zesen Qian:
> Noel Kuntze <noel at familie-kuntze.de> writes:
>
>> Hello Zesen,
>>
>> It matters. IPv4 traffic is filtered by the firewall that you configure using iptables
>> and IPv6 traffic is filtered by the firewall that you configure using ip6tables.
>> If you use a 4in6 tunnel, you need let the IPv6 tunnel packets through by configuring
>> the firewall for IPv6 traffic using ip6tables. The traffic that is encapsulated in the tunnel packets
>> is filtered by the firewall you configure using iptables.
>> What you except from NAT are not the ESP or ESPINUDP packets, but the packets
>> that are supposed to be in there. The policy match module tries to find
>> an IPsec policy (XFRM policy on Linux) that matches the packet.
>> Using it in the ACCEPT rule prevents the NAT from being applied to packets that match a policy,
>> to make sure that the packets go into the tunnel and still match the policy when the XFRM lookup
>> happens. See [1] for the packet flow in Netfilter and general networking on Linux.
>> Netfilter is the firewall implementation on Linux.
>>
>> [1] http://inai.de/images/nf-packet-flow.png
>>
>>
>> Mit freundlichen Grüßen/Regards,
>> Noel Kuntze
>>
>> GPG Key ID: 0x63EC6658
>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>
>> Am 24.12.2014 um 14:44 schrieb Zesen Qian:
>>> Noel Kuntze <noel at familie-kuntze.de> writes:
>>>
>>>> Oh, and furthermore,
>>>> 1) you also need to except IPsec traffic from NAT on your client.
>>>> 2) You need to clean up your MASQUERADE rules on your server.
>>>>     A correct iptables rule set for you looks like this:
>>>>     iptables -t nat -A POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
>>>>     iptables -t nat -A POSTROUTING -o venet0 -j MASQUERADE
>>>>
>>>> Mit freundlichen Grüßen/Regards,
>>>> Noel Kuntze
>>>>
>>>> GPG Key ID: 0x63EC6658
>>>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>>>
>>>> Am 24.12.2014 um 12:09 schrieb Zesen Qian:
>>>>> Noel Kuntze <noel at familie-kuntze.de> writes:
>>>>>
>>>>>> Hello Zesen,
>>>>>>
>>>>>> You do not need a virtual IP. Route 10.0.0.0/0 == 0.0.0.0/0 throught the tunnel
>>>>>> and use a passthrough policy of 10.0.0.0/0 == 10.0.0.0/0 to allow local traffic.
>>>>>> Make the hosts in the LAN use your old notebook as gateway for the default route
>>>>>> and it will work. I did that here at my place and it works just fine.
>>>>>> See [1] for some explanation on getting routing to work.
>>>>>>
>>>>>> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling
>>>>>>
>>>>>> Mit freundlichen Grüßen/Regards,
>>>>>> Noel Kuntze
>>>>>>
>>>>>> GPG Key ID: 0x63EC6658
>>>>>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>>>>>
>>>>>> Am 23.12.2014 um 02:47 schrieb Zesen Qian:
>>>>>>> Hi all,
>>>>>>> I 'm configuring a special roadwarrior and I'm quite new to IPsec world,
>>>>>>> so plz correct me if I'm wrong. :-)
>>>>>>> I want to config it in such way:
>>>>>>>
>>>>>>> 0. Riaqn-Laptop is my old laptop acting as gateway in my home, the lan
>>>>>>> is 10.0.0.0/24, and the external IP is dynamically allocated.
>>>>>>> Riaqn-VPS is VPS, which has a static IP(that Riaqn-Laptop can
>>>>>>> connect to).
>>>>>>>
>>>>>>> 1. Laptop as initiator, VPS as responder. Once the connection is
>>>>>>> established, Laptop give the VPS a virtual IP in 10.0.0.0/24 (just as
>>>>>>> the local lan machines). Does dhcp and farp plugin do the trick?
>>>>>>>
>>>>>>> 2. Then all outgoing traffic in the lan goes through IPsec, that is, if
>>>>>>> a normal computer in the lan connecting a outside server, the server
>>>>>>> should see the VPS's IP.
>>>>>>>
>>>>>>> Is it possible by strongswan? I 've seen lots of config examples on
>>>>>>> strongswan website, but none of which is like what I said. I have
>>>>>>> strugled for more than a week... BTW, is there any good article that
>>>>>>> explains about traffic selector/routing in IPsec(for a beginner)?
>>>>>>> Any comments is appreciated!
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.strongswan.org
>>>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>>>
>>>>> Hi Noel,
>>>>>    Thanks for your reply!
>>>>>    I checked the URL and tried to understand it. Then I configure in
>>>>>    such a way:
>>>>>    1. server and client ipsec.conf is here[1]:
>>>>>    2. I do some iptables stuff on the server side, just as the URL says:
>>>>>       iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o venet0 -j MASQUERADE
>>>>>       iptables -t nat  -A POSTROUTING -s 10.0.0.0/24 -o venet0 -m policy --dir out --pol ipsec -j ACCEPT
>>>>>    3. Then I up the client. Once the connection is established, the
>>>>>    client 's connection to everything(to Internet, to LAN) seems cut-up.
>>>>>    Outer world cannot ping the client(gateway), and LAN machines
>>>>>    cannot connect to it, either.
>>>>>    4. However, I can connect the client from the server. I typed
>>>>>    ssh 10.0.0.1 to check what happens. So this is what it looks like on
>>>>>    client [2]
>>>>>    5. And this is what it looks like on server [3]
>>>>>
>>>>>    Would you help me check these infos please? BTW, do you know any
>>>>>    articles explaining traffic selector/routing/stuff? I 'm really
>>>>>    confused how IPsec is integrated into my network..
>>>>>
>>>>> [1] https://bpaste.net/show/45dcd2c1100d
>>>>> [2] https://bpaste.net/show/e2add2951990
>>>>> [3] https://bpaste.net/show/96a7300a7e73
>>>>
>>> Hi Noel,
>>>    I have place the ACCEPT before the MASQUERADE. There 's MASQUERADE on
>>>    10.8.0.0/24 on server because it's my OpenVPN server too, does it
>>>    matter?
>>>    I 'm doing a IPv4-in-IPv6 tunnel, so I suppose there 's no need to
>>>    except IPsec traffic fron nat? Here 's the ip6tables on the client:
>>>    # Generated by ip6tables-save v1.4.21 on Tue Dec 23 08:34:38 2014
>>>    *filter
>>>    :INPUT ACCEPT [14:2201]
>>>    :FORWARD ACCEPT [0:0]
>>>    :OUTPUT ACCEPT [13:1102]
>>>    COMMIT
>>>    # Completed on Tue Dec 23 08:34:38 2014
>>>
>>>    as you can see, it just ACCEPT all traffic.
>>>
>>>    Then I tried to up the client again, and the problem still...
>>>
>>
>
> Hello Noel,
>       It may be related to my home-setup smtp server, please try
>       me at riaqn.com.
>       Remember you told me to "except IPsec traffic from NAT"? Actually
>       I'm new to not only IPsec, but also iptables. Can you give some
>       guide on how to do it?
>       Oh, and more. I just retried to up the ipsec on client, and
>       surprisingly, the machine in the client LAN can still connect to
>       the client. The disconnect only happens between client and
>       external net(except the server). Sorry that I provided wrong info
>       on the problem.
>      

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUnXcwAAoJEDg5KY9j7GZYzxMP/19agOSQIa2DA5aVazRUN7/T
otTLiHt5B+JC5CYQBBPxhcZ/mFgKD4ZH1iFTMMER1AhMV1Y5tCWsNP5hrbmjdOAy
FRe0OR35Xj5M5cpHCgRq/hxuOz1bESbTipDQzWWvSN+X5h9ssrcDpCjp48EclZVv
vY5UrrzOGyf+s2eDzaLDak9k6imvkxAnB5pVwmagndXZaMGHAFrjezs4AgCpBczO
EJYou8jPRiIGrOZuuB/ugHZlXofkllnsyz1GHOkZQhAkdYDYaU3aw58FCFnovVKC
AD5XfOpYPLubPXQZG4gM1oWQte3FdInKhRiF5G/u36rTVyhcqjrA2lr5iqoSZQPJ
Z5uZeYbQfeqeNONJdf2QXLbdFSEcTLG8tHEQMiwP4c1bB2m+O40hWbiPefiMCyZu
ukJH0JulP9g1KYMflxpxWQefmY8PPe705/s6q2Didzbx0PMeQNN3lmyHOogXpUBr
bmP2c78qmI+x0Q9U1CHHUeR78MeDiOUO4CA+QALNOP/wxnkJ6DVGiAUEDXTfFjyb
uOlWeNGNKwKxgU+Pxw5C2RBUaoWWc068SP8nAA6VThQKUtQjMgB6xHse0k3t2aYk
Fj704a5Pq7giv8TR/admDQ8blgrd/CTBdSH5trEoTVcfxEwrLrJcf6F0WszsvN49
pUYD3HeDy7/LRUYx/UWt
=IhWE
-----END PGP SIGNATURE-----