[strongSwan] Strongswan failed to forward decrypted packet to socket

Quaker bigboyq at gmail.com
Fri Dec 22 04:06:24 CET 2017


from server alpha:
----------------------------------------------------------------------------------------------------------------------
ipsec statusall

Status of IKE charon daemon (strongSwan 5.6.1, Linux 2.6.32-042stab123.3,
x86_64):
  uptime: 106 seconds, since Dec 22 10:43:25 2017
  malloc: sbrk 1486848, mmap 0, used 400416, free 1086432
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0,
scheduled: 0
  loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509
revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey
pem openssl fips-prf curve25519 xcbc cmac hmac attr kernel-libipsec
kernel-netlink resolve socket-default stroke vici updown eap-identity
eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap
eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp certexpire radattr
addrblock unity counters
Listening IP addresses:
  138.128.199.83
Connections:
          rw:  138.128.199.xx...198.181.41.xx  IKEv2
          rw:   local:  [138.128.199.xx] uses pre-shared key authentication
          rw:   remote: [198.181.41.xx] uses pre-shared key authentication
          rw:   child:  dynamic === dynamic TUNNEL
Security Associations (0 up, 0 connecting):
  none

----------------------------------------------------------------------------------------------------------------------
sysctl -A | grep rp_filter

sysctl: separators should not be repeated: /.fake
sysctl: separators should not be repeated: /.fake
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.venet0.rp_filter = 1
net.ipv4.conf.venet0.arp_filter = 0
net.ipv4.conf.ipsec0.rp_filter = 0
net.ipv4.conf.ipsec0.arp_filter = 0
----------------------------------------------------------------------------------------------------------------------
ip route show table all

198.181.41.xx dev ipsec0  table 220  proto static  src 138.128.199.xx
default dev venet0  scope link
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link
src 127.0.0.1
local 138.128.199.xx dev venet0  table local  proto kernel  scope host  src
138.128.199.xx
broadcast 138.128.199.xx dev venet0  table local  proto kernel  scope link
src 138.128.199.xx
local 127.0.0.2 dev venet0  table local  proto kernel  scope host  src
127.0.0.2
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src
127.0.0.1
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src
127.0.0.1
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src
127.0.0.1
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
error -101 hoplimit 255
default dev venet0  metric 1  mtu 1500 hoplimit 0
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
error -101 hoplimit 255
local ::1 via :: dev lo  table local  proto none  metric 0  mtu 65536
hoplimit 0
unreachable default dev lo  table unspec  proto kernel  metric 4294967295
error -101 hoplimit 255

----------------------------------------------------------------------------------------------------------------------
ip rule

0:      from all lookup local
220:    not from all fwmark 0x4 lookup 220
32766:  from all lookup main
32767:  from all lookup default


-----------------------------------------------------------------------------------------------------------------------
if I ping from beta to alpha

root at bwg:~# tcpdump -n -i ipsec0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type RAW (Raw IP), capture size 262144 bytes
11:01:46.158074 IP 138.128.199.xx > 198.181.41.xx: ICMP echo request, id
574, seq 1, length 64
11:01:47.157528 IP 138.128.199.xx > 198.181.41.xx: ICMP echo request, id
574, seq 2, length 64
11:01:48.157531 IP 138.128.199.xx > 198.181.41.xx: ICMP echo request, id
574, seq 3, length 64


root at bwg:~# tcpdump -n host 198.181.41.xx
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
11:02:58.797762 IP 198.181.41.xx.4500 > 138.128.199.xx.4500: UDP-encap:
ESP(spi=0xa02b7290,seq=0x4e), length 136
11:02:59.796353 IP 138.128.199.xx.4500 > 198.181.41.xx.4500: UDP-encap:
ESP(spi=0xc33ec88a,seq=0x4f), length 136
11:02:59.797232 IP 198.181.41.xx.4500 > 138.128.199.xx.4500: UDP-encap:
ESP(spi=0xa02b7290,seq=0x4f), length 136
11:03:00.796608 IP 138.128.199.xx.4500 > 198.181.41.xx.4500: UDP-encap:
ESP(spi=0xc33ec88a,seq=0x50), length 136
11:03:00.797379 IP 198.181.41.xx.4500 > 138.128.199.xx.4500: UDP-encap:
ESP(spi=0xa02b7290,seq=0x50), length 136
11:03:01.796649 IP 138.128.199.xx.4500 > 198.181.41.xx.4500: UDP-encap:
ESP(spi=0xc33ec88a,seq=0x51), length 136
11:03:01.797435 IP 198.181.41.xx.4500 > 138.128.199.xx.4500: UDP-encap:
ESP(spi=0xa02b7290,seq=0x51), length 136



Regards
Quaker

On Fri, Dec 22, 2017 at 7:00 AM, Noel Kuntze <
noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:

> There have previously been problems with running XFRM in OpenVZ containers
> (meaning it didn't work at all, despite claims of the OpenVZ developers it
> did).
>
> Please provide the following outputs:
> ipsec statusall (or swanctl -l, if you use swanctl)
> sysctl -A | grep rp_filter
> ip route show table all
> ip rule
> 'tcpdump -n -i ipsec0' when you're trying to connect over the tunnels
>
>
> On 19.12.2017 08:57, Quaker wrote:
> > I am using Strongswan 5.6.1 on my OpenVZ servers
> > And strongswan 5.6.1 is compiled by myself. kernel-libipsec enabled by
> > ./configure --enable-eap-identity --enable-eap-md5 \
> --enable-eap-mschapv2 --enable-eap-tls --enable-eap-ttls --enable-eap-peap
> \ --enable-eap-tnc --enable-eap-dynamic--enable-eap-radius
> --enable-xauth-eap \ --enable-xauth-pam --enable-dhcp --enable-openssl
> --enable-addrblock --enable-unity \ --enable-certexpire --enable-radattr
> --enable-tools --enable-openssl --disable-gmp --enable-kernel-libipsec
> > the strongswan.conf configuration modified as :
> >
> > charon {
> >         load_modular = yes
> >         plugins {
> >                 include strongswan.d/charon/*.conf
> >                 kernel-netlink {
> >                         fwmark = !0x4
> >                 }
> >                 socket-default {
> >                         fwmark = 0x4
> >                 }
> >                 kernel-libipsec {
> >                         allow_peer_ts = yes
> >                 }
> >         }
> > }
> > I have created ipsec tunnel successfully between my OpenVZ server alpha
> and beta:
> > But the socket connection fails.
> > By investigate the problem, I tried tcpdump, found that
> > If I ping from alpha to beta
> > tcpdump could found
> > esp from alpha->beta
> > esp from beta->alpha
> > but ping timeout
> >
> > If I ping from beta to alpha
> > tcpdump could found
> > esp from beta->alpha
> > and ping timeout
> >
> > if using tcp, and answer is similar
> > alpha->beta
> > alpha SYN_SENT
> > beta SYN_RECV
> >
> > beta->alpha
> > beta SYN_SENT
> > alpha NULL
> >
> > I guess there should be some problem during esp to socket
> > anyone could tell me how to detect the problem, or some further
> information should I give.
> >
> > alpha and beta belongs to different OpenVZ supplier, don't know the
> problem.
> > I have reinstalled alpha sometimes, but doesn't work.
> >
> > beta:Linux beta 2.6.32-042stab125.5 #1 SMP Tue Oct 17 12:48:22 MSK 2017
> x86_64 GNU/Linux
> >
> > alpha: Linux alpha 2.6.32-042stab123.3 #1 SMP Fri May 5 12:29:05 MSK
> 2017 x86_64 GNU/Linux
> >
> > Regards
> > Quaker
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171222/a56fb406/attachment.html>


More information about the Users mailing list