[strongSwan] roadwarrior as gateway, possible?
Noel Kuntze
noel at familie-kuntze.de
Sun Dec 28 03:07:37 CET 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJUn2XmAAoJEDg5KY9j7GZY6ZsP/jyzAYQQSRdi5LgBUqGXeUmL
bc7RQaPBFDlCJKRe46szZm/a4XFPPBNf2WoJyPKWisXTLi9UUKOrhWhwuf+HechE
x1g/vjpA7zKlCOKntf3rvsJcqZxxLpGL35dc2AGEjms0wi1jnoFEcAFISEJnW+nn
gQCoRKBDCuOw0O3rC8mUSfSCFkiQwWwqFtc/mfOvlaC5iUYPiIg9S4B/fmUR3ctu
SkQVWmElfJdla+j4/iEj2HkAbpObJ7w8udwljqGIo1lfqPfc6SriUDY5Ngm2qcjQ
jazsVBHNlTT5NL2S/4HG3ZR5GfkYupOtJRBScqUKOAT5VojKeBIZb+XWAbOqZenm
N79wF/wdR1kWOIHZrBm4J1GnKMdXesHnSjwaZaog4FW3wMf6qwm/q4pgxqqLyQc1
W24HZRO8cPSm/oBxiOK03Im5gmVPGTMuX/gV4/APqUxgY13EHROV1mElM/U7+DZu
HwyFWIpnH16drgKK4ly3aolT+g+FbIR5IUOdZ+p/RYMzrNq/9bFsxDe+9KCFQZ2Q
6NDvjANb8gq86QT0gQWPtN3cGj4dVDIUnRFdSrvmdFRQKW5N9sKUz5Kq9wZ6a5KG
oYeiXiaP1tqtQ0ud9Enbf8Gz1bXwHGhe+3JKtuWo3Jl6gSK1XVFA4GR68xHKWd3N
/X+73Y0o1LteppxFLSDa
=JR4f
-----END PGP SIGNATURE-----
More information about the Users
mailing list