[strongSwan] roadwarrior as gateway, possible?
Zesen Qian
strongswan-users at riaqn.com
Sun Dec 28 02:13:21 CET 2014
Hello Noel,
Here comes:
Riaqn-RamNode ~ # ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 2.6.32-042stab093.5, x86_64):
uptime: 3 days, since Dec 25 08:07:50 2014
malloc: sbrk 2506752, mmap 0, used 419296, free 2087456
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default socket-dynamic stroke vici updown xauth-generic xauth-pam lookip led unity
Listening IP addresses:
167.88.115.14
107.191.117.37
2604:180:1::aca1:be20
2604:180:1::e96:5e60
2604:180:1::802d:7284
2604:180:1::e0d7:4bdf
2604:180:1::56f3:9eb
2604:180:1::4780:e0e9
2604:180:1::f47d:cf0a
2604:180:1::34ec:c3e7
2604:180:1::1a3e:1084
2604:180:1::2d7f:851
2604:180:1::1eb4:5098
2604:180:1::63cd:6a52
2604:180:1::a3e:3ce0
2604:180:1::ec2f:e6ca
2604:180:1::7261:23d1
2604:180:1::2974:e50c
10.8.0.1
Connections:
vps-dorm: %any...%any IKEv2
vps-dorm: local: [C=US, ST=WA, L=Seattle, O=Riaqn, CN=Riaqn-RamNode, N=Riaqn-RamNode, E=ramnode at riaqn.com] uses public key authentication
vps-dorm: cert: "C=US, ST=WA, L=Seattle, O=Riaqn, CN=Riaqn-RamNode, N=Riaqn-RamNode, E=ramnode at riaqn.com"
vps-dorm: remote: uses public key authentication
vps-dorm: child: 0.0.0.0/0 === 10.0.0.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
vps-dorm[42]: ESTABLISHED 94 seconds ago, 2604:180:1::ec2f:e6ca[C=US, ST=WA, L=Seattle, O=Riaqn, CN=Riaqn-RamNode, N=Riaqn-RamNode, E=ramnode at riaqn.com]...2001:da8:8000:e0b1::cdf4[C=US, ST=WA, L=Seattle, O=Riaqn, CN=Riaqn-Laptop, N=Riaqn-Laptop, E=laptop at riaqn.com]
vps-dorm[42]: IKEv2 SPIs: 5c03263cb823f68e_i 3c99a122b679a6ac_r*, public key reauthentication in 54 minutes
vps-dorm[42]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
vps-dorm{60}: INSTALLED, TUNNEL, ESP SPIs: c53f5f43_i cd177fb5_o
vps-dorm{60}: AES_CBC_128/HMAC_SHA1_96, 656 bytes_i (11 pkts, 8s ago), 5964 bytes_o (71 pkts, 8s ago), rekeying in 13 minutes
vps-dorm{60}: 0.0.0.0/0 === 10.0.0.0/24
Riaqn-RamNode ~ # iptables-save
# Generated by iptables-save v1.4.21 on Sun Dec 28 09:04:07 2014
*raw
:PREROUTING ACCEPT [88089691:85423486883]
:OUTPUT ACCEPT [29171524:13640803068]
COMMIT
# Completed on Sun Dec 28 09:04:07 2014
# Generated by iptables-save v1.4.21 on Sun Dec 28 09:04:07 2014
*nat
:PREROUTING ACCEPT [7056:415098]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [10097:631614]
-A POSTROUTING -o venet0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -o venet0 -j MASQUERADE
COMMIT
# Completed on Sun Dec 28 09:04:07 2014
# Generated by iptables-save v1.4.21 on Sun Dec 28 09:04:07 2014
*filter
:INPUT ACCEPT [147:9644]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [153:17272]
-A FORWARD -s 10.0.0.0/24 -i venet0 -m policy --dir in --pol ipsec --reqid 60 --proto esp -j ACCEPT
-A FORWARD -d 10.0.0.0/24 -o venet0 -m policy --dir out --pol ipsec --reqid 60 --proto esp -j ACCEPT
COMMIT
# Completed on Sun Dec 28 09:04:07 2014
# Generated by iptables-save v1.4.21 on Sun Dec 28 09:04:07 2014
*mangle
:PREROUTING ACCEPT [101152982:95192590982]
:INPUT ACCEPT [43814902:45585110056]
:FORWARD ACCEPT [57337767:49607441902]
:OUTPUT ACCEPT [33903139:16379275756]
:POSTROUTING ACCEPT [91017821:65675753605]
COMMIT
# Completed on Sun Dec 28 09:04:07 2014
Riaqn-RamNode ~ # sysctl -A |grep -i forwarding
sysctl: separators should not be repeated: /.fake
sysctl: separators should not be repeated: /.fake
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.venet0.forwarding = 1
net.ipv4.conf.venet0.mc_forwarding = 0
net.ipv4.conf.gre0.forwarding = 1
net.ipv4.conf.gre0.mc_forwarding = 0
net.ipv4.conf.gretap0.forwarding = 1
net.ipv4.conf.gretap0.mc_forwarding = 0
net.ipv4.conf.ip6tnl0.forwarding = 1
net.ipv4.conf.ip6tnl0.mc_forwarding = 0
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.tun0.mc_forwarding = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.venet0.forwarding = 1
net.ipv6.conf.venet0.mc_forwarding = 0
net.ipv6.conf.gre0.forwarding = 1
net.ipv6.conf.gre0.mc_forwarding = 0
net.ipv6.conf.gretap0.forwarding = 1
net.ipv6.conf.gretap0.mc_forwarding = 0
net.ipv6.conf.ip6tnl0.forwarding = 1
net.ipv6.conf.ip6tnl0.mc_forwarding = 0
net.ipv6.conf.tun0.forwarding = 1
net.ipv6.conf.tun0.mc_forwarding = 0
Noel Kuntze <noel at familie-kuntze.de> writes:
> 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!
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
--
Zesen Qian (钱泽森)
More information about the Users
mailing list