[strongSwan] roadwarrior as gateway, possible?
Zesen Qian
strongswan-users at riaqn.com
Sun Dec 28 08:33:28 CET 2014
Hello Noel,
Seems that someone already post a issue for the exactly same
problem[1], so I add the link here for the completeness, also for
the convenience of people who encounter this problem in future.
I will try the same setup on Xen/KVM and report if not work. Thanks!
[1] https://wiki.strongswan.org/issues/592
Noel Kuntze <noel at familie-kuntze.de> writes:
> Hello Zesen,
>
> Yes, it matters, because strongSwan doesn't work correctly or not at all on container virtualized systems.
> Yes, libipsec is a user space implementation of IPsec and yes, the major advantage over OpenVPN less
> overhead. Switching to Xen/KVM is indeed the way to go.
>
> Mit freundlichen Grüßen/Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
> Am 28.12.2014 um 02:53 schrieb Zesen Qian:
>> Hello Noel,
>> Yes, It's an OpenVZ container, but why that matters? It looks like
>> the packet is received and decapsulated correctly, and the only
>> problem is NAT...
>> Also, I read that libipsec is a userspace IPsec implementation. I
>> was told that the major advantage of IPsec over OpenVPN is that,
>> it's purely kernel code and less overhead on context switching.
>> libipsec looks quite similar to OpenVPN(userspace, TUN)? If that's
>> the case I 'm willing to switch to Xen/KVM to gain better
>> performance.
>> Please correct me if I 'm wrong. :-) Thanks!
>>
>> Noel Kuntze <noel at familie-kuntze.de> writes:
>>
>>> Hello Zesen,
>>>
>>> Is that a container virtualized VM? If so, you need to change to using kernel-libipsec and libipsec (processing of esp in user space).
>>> Refer to [1] for instructions. Furthermore, you need to use a custom
>>> charon.load statement in /etc/strongswan.conf to only load said
>>> backend and not other backends.
>>> Get the list of loaded plugins with "ipsec statusall" and remove all
>>> other backends. Then copy said list to charon.load and append
>>> kernel-libipsec and libipsec.
>>>
>>> [1] https://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec
>>>
>>>
>>> Mit freundlichen Grüßen/Regards,
>>> Noel Kuntze
>>>
>>> GPG Key ID: 0x63EC6658
>>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>>
>>> Am 28.12.2014 um 02:13 schrieb Zesen Qian:
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.strongswan.org
>>> https://lists.strongswan.org/mailman/listinfo/users
>>
>
--
Zesen Qian (钱泽森)
More information about the Users
mailing list