[strongSwan] roadwarrior as gateway, possible?
Zesen Qian
strongswan-users at riaqn.com
Sat Dec 27 06:26:05 CET 2014
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!
--
Zesen Qian (钱泽森)
More information about the Users
mailing list