[strongSwan] roadwarrior as gateway, possible?
Noel Kuntze
noel at familie-kuntze.de
Sun Dec 28 02:23:17 CET 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJUn1uCAAoJEDg5KY9j7GZYr8YP/RJMF1IBMHXtJK5rARrTMTCC
0LwZqFSZW2NIU/3CskI+TVqrrTmTr1eLVrYU5PcQ1S40NxcIkfYWvcT7Be7VVQU6
w9ELCAnqKY1WmPp0IrjRgtWo4SQv+VHDys+I+iMyzzmai/4hZvl89zZcSoQir9yG
WME5UM2zLgX/aCeaWk6c9bKEvd29EX8+OC4XaSxwDJPTDX2JSTP+cF8oN2WOv1I4
stitjaLDSsMsTtwyhCl4DVaCMYj2j7freiqMkVmMEwutCf9lmyGyzcXEke2yJYqa
oUBUNQi+enOvCp+hm2d+0EBc0TqgN8kGvUrin8OWDtQcSHXDEu1ntfbtPI4NoThA
VsP6f5IjuTurRS0Y84iznTfZwXs17YZcwAjqrFEo8km0x/n4nSvAtKlNB/7v6+CU
YqvBzrtoZCkAWkZF7bMrmeOxwMdPP1Xbz1DHE6gdS8xk6OeRNLWjKpCMod0yj6d6
JjPwrFOK3ltGujLLV/P3QJfo0ULV+X7eDdL8lpI6JJ2pIPTCNiOGOLYi8qkBNjbO
eVPIocY8aNJxnJvk56xloJZfvZLdHtAGtThlLmtgYPnemEoxeaIb/raQQPHVekVz
Tr7IIvTgS03yQXeCvwPgQY50O15J7qHHgvg6wuIjINaM5Slo5i+4IWcRpltPIO1b
OgWW1nPE/55ZUi0Kkll1
=zueC
-----END PGP SIGNATURE-----
More information about the Users
mailing list