[strongSwan] roadwarrior as gateway, possible?
Noel Kuntze
noel at familie-kuntze.de
Sat Dec 27 18:31:36 CET 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello Zesen,
Please show me the complete output of "ipsec statusall", "iptables-save" and
"sysctl -A | grep forwarding" on A.
Mit freundlichen Grüßen/Regards,
Noel Kuntze
GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
Am 27.12.2014 um 06:26 schrieb Zesen Qian:
> Noel Kuntze <noel at familie-kuntze.de> writes:
>
>> 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.
>>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
> Hello Noel,
> Thanks, your issue report describes exactly my problem, if I have
> further discovering, I shall add comment to it.
> Back to my site-to-site problem, after except IPsec traffic from
> NAT, now I can confirm that all traffic from the LAN to internet
> is routed to VPS. But I cannot connect to outer world still. Here
> is the situation:
> A is server(VPS, 88.88.88.88), B is client(gateway, 10.0.0.1), C is a machine in the LAN(10.0.0.80)
> Now these 3 can ping each other perfectly.
> But C cannot ping outer world, except A.
>
> Here is the tcpdump on A when C doing an HTTP request to outer world:
> Riaqn-RamNode ~ # tcpdump|grep -i 23.251.
> error : ret -1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
> 13:02:46.010603 IP 10.0.0.76.60106 > 23.251.96.131.http: Flags [S], seq 1600947560, win 29200, options [mss 1460,sackOK,TS val 343383388 ecr 0,nop,wscale 7], length 0
> 13:02:46.010679 IP Riaqn-RamNode.60106 > 23.251.96.131.http: Flags [S], seq 1600947560, win 29200, options [mss 1460,sackOK,TS val 343383388 ecr 0,nop,wscale 7], length 0
> 13:02:46.209678 IP 10.0.0.76.34240 > 23.251.100.132.http: Flags [S], seq 2142527590, win 29200, options [mss 1460,sackOK,TS val 343383588 ecr 0,nop,wscale 7], length 0
> 13:02:49.012749 IP 10.0.0.76.60106 > 23.251.96.131.http: Flags [S], seq 1600947560, win 29200, options [mss 1460,sackOK,TS val 343386392 ecr 0,nop,wscale 7], length 0
> 13:02:49.012801 IP Riaqn-RamNode.60106 > 23.251.96.131.http: Flags [S], seq 1600947560, win 29200, options [mss 1460,sackOK,TS val 343386392 ecr 0,nop,wscale 7], length 0
> 13:02:49.212816 IP 10.0.0.76.34240 > 23.251.100.132.http: Flags [S], seq 2142527590, win 29200, options [mss 1460,sackOK,TS val 343386592 ecr 0,nop,wscale 7], length 0
> 13:02:49.212868 IP Riaqn-RamNode.34240 > 23.251.100.132.http: Flags [S], seq 2142527590, win 29200, options [mss 1460,sackOK,TS val 343386592 ecr 0,nop,wscale 7], length 0
>
> as you can see, the NAT seems working: it translate the 10.0.0.76
> to its own IP, and forward it. What 's weird is that there 's no
> response from the outer server. If I use openvpn:
>
> Riaqn-RamNode ~ # tcpdump|grep -i 23.251.
> error : ret -1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
> 13:14:57.662330 IP Riaqn-RamNode.44776 > 23.251.96.131.http: Flags [S], seq 2393963846, win 29200, options [mss 1368,sackOK,TS val 36246251 ecr 0,nop,wscale 7], length 0
> 13:14:57.696265 IP 23.251.96.131.http > Riaqn-RamNode.44776: Flags [S.], seq 4128795364, ack 2393963847, win 14480, options [mss 1460,sackOK,TS val 645237371 ecr 36246251,nop,wscale 7], length 0
> 13:14:58.834637 IP Riaqn-RamNode.46481 > 23.251.100.132.http: Flags [S], seq 3193651221, win 29200, options [mss 1368,sackOK,TS val 36246369 ecr 0,nop,wscale 7], length 0
> 13:14:58.863071 IP 23.251.100.132.http > Riaqn-RamNode.46481: Flags [S.], seq 3921369728, ack 3193651222, win 63443, options [mss 1460,nop,wscale 6,nop,nop,sackOK], length 0
>
> There's no log about the packet from/to lan(10.8.0.0/24), but packet replied
> from the outer server.
>
> BTW, I don't know if it's related, here is iptables on A:
>
> Riaqn-RamNode ~ # iptables -t nat -nvL
> Chain PREROUTING (policy ACCEPT 3460 packets, 204K bytes)
> pkts bytes target prot opt in out source destination
>
> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 ACCEPT all -- * venet0 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec
> 6160 416K MASQUERADE all -- * venet0 0.0.0.0/0 0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT 5028 packets, 319K bytes)
> pkts bytes target prot opt in out source destination
>
> seems that the first ACCEPT matches no packet?
> I think it's more an iptables problem than IPsec, but I would
> appreciate it if you get time to help me out!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJUnuz2AAoJEDg5KY9j7GZYuN8P+wSJ6hwX2HZ3XxQ2knM/rPON
F/cQzu9CtQMZy6lg5BnsJTGclBiuvNL/NAZvcbg7gwssWGapB+FLIJgrdPrAOr3z
q0qpscx0Dr3JVI1vDG8cwFIGgG2pMRtEiO9Ar/AavtcwqfwAnKBOPIgi0Raoxmh1
ghgCDZNni7ukkyTHOMFSYRjsYSns6YEvtr5MMJsfiGOCrSq00lNyNepnuWZu0bdb
E/pU/H1B8yKVcUH3TmPcDCmjnlRvXN+j1vt4yxrevhOMD69VWNI110IS4j/PF/Lc
BhOahK2ZUFXzOPyTLQkb8DmxqkI7ZGq7Cys0a7oD+EqF7cGUNM5aOkxC/l8gARyv
T4n/c/5ziRuddjHi7Tqh4w3DZfxtElzUrv18eAvT45vcgw+f0GAZvfAlKAMsM6IL
5jVan20Dk6iUz/p6apuf8wg09Lb4OhnQgeWTWRqXRnZuAO5xlYoD1y84LREO/Lao
jZuRi2IMESzrH0oaEHEgZcazDJrRx3Js3jKY0S3C5ZfMFFoqQfi9GkKGqYhq2iAl
+0WpCuA6tz4BusGn/x27+IfDvQoN2L2gAf7JWhy3XrkELw2mUuFPTCX6t05+kueV
/N3UNKVS1xWMOKtpP3dWm5oD4AqCd2ghkQ3V8MX/arlbiXuG3A6n+d5Ff3V9XRUF
k7sx8RBhZTuK4MmTFV0x
=8oQL
-----END PGP SIGNATURE-----
More information about the Users
mailing list