[strongSwan] roadwarrior as gateway, possible?

Wed Dec 24 15:08:24 CET 2014

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

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...
>

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

iQIcBAEBCAAGBQJUmsjWAAoJEDg5KY9j7GZY/nAQAJKizcc5ACF6n5y9aSmJ6K+P
VFiqMC8+AZJHcCKiOVGVyJbRM40UQP6PCDQHRrZ9ftkz8DyA3mzp5eaTb6Wdi/ah
5oRfH1W9TBQBaFJ27JFGhafVgwxXw795PFOq73BNB2Mc/jV4h7dFL+6H6jRjENgd
w4WPFXpV8I+ZeuH/djiygRurg5Yc6/4mTYJEQXUxno1bYByIRXb1I6B0uF9lflUH
DsH+jo0Wv4dpkBhG8m+01lfIL9jKINB4+CCZSPV7zhGC47bRwhCaUp5AOoplVVKN
rnpluhK+XTWgiyr58RFchJ7MtMKGsNIf5T5ZbYTFJZT52FC/obfpLhTFHY0x8fVO
oMVoqTIX9bBw5Hw49tftrMjJcXGVcAgTvWhITBS4GkCptaVAjNXxrxpk1zsqxLbF
ViEG+NU4pOnZWGf0FZHNwMWZF9oqHXmEruGOMrc4HfzlY+Le8p1YwCv0rUF6b2pd
V35WDhBQBY4HLkfsrtqk+KSx5mgZ/AwYNQ0YpGCkhZzekMFM9MPoGfAU4jS+mPbn
GtI6UBs6YjJqxEd6y+WseKXrXcWD8vwBjgYiu8hx3ZT3+XTc2EKEIoTOJcxrZSCc
539Ue5RIJuPzBMQlc/PbOUsQA4331R7jCxI1oMsLjHrr5F+0cQs+dFakNCp1SEnG
ZRD9syRQzYjTtZ9t4f/f
=8yJO
-----END PGP SIGNATURE-----