Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSEC tunnel up but only one way communication

    Scheduled Pinned Locked Moved IPsec
    1 Posts 1 Posters 177 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Z
      zacha
      last edited by

      Hello!

      I am trying to set up L2TP over IPSec client to a foreign VPN. I cannot change any parameters of the other side. I have successfully configured IPSEC phase 1 and phase 2. At least the connection comes up and seems to be running.

      Status of IKE charon daemon (strongSwan 5.8.2, FreeBSD 11.3-STABLE, amd64):
      uptime: 3 hours, since May 24 14:44:42 2020
      worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 14
      loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac drbg curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam whitelist addrblock counters
      Listening IP addresses:
      [...]
      93.23x.y.z
      [...]
      Connections:
      bypasslan: %any...%any IKEv1/2
      bypasslan: local: uses public key authentication
      bypasslan: remote: uses public key authentication
      bypasslan: child: xxxxxx/24|/0 === xxxxx/24|/0 PASS
      con1000: 93.23x.y.z...194.x.y.z IKEv1, dpddelay=10s
      con1000: local: [93.23x.y.z] uses pre-shared key authentication
      con1000: remote: [194.x.y.z] uses pre-shared key authentication
      con1000: child: 93.23x.y.z/32|/0 === 194.x.y.z/32|/0 TRANSPORT, dpdaction=restart
      Shunted Connections:
      bypasslan: xxxxx/24|/0 === xxxxx/24|/0 PASS
      Routed Connections:
      con1000{7}: ROUTED, TRANSPORT, reqid 1
      con1000{7}: 93.23x.y.z/32|/0 === 194.x.y.z/32|/0
      Security Associations (1 up, 0 connecting):
      con1000[4]: ESTABLISHED 75 minutes ago, 93.23x.y.z[93.23x.y.z]...194.x.y.z[194.x.y.z]
      con1000[4]: IKEv1 SPIs: d0db7d496bffdb2f_i* 2b2d0561d9ed9c71_r, pre-shared key reauthentication in 6 hours
      con1000[4]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      con1000{19}: INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c8f1bd4f_i c15317a9_o
      con1000{19}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i (0 pkts, 4501s ago), 50968 bytes_o (277 pkts, 2s ago), rekeying in 17 minutes
      con1000{19}: 93.23x.y.z/32|/0[udp] === 194.x.y.z/32|/0[udp/l2f]

      As you can see the are two SAs for both directions. When monitoring on the parent WAN interface with tcpdump I can see ESP packets going for out SA c15317a9_o and returning for c8f1bd4f_i. So the remote side is answering. But as you can see it seems that strongswan either does not receive those packets or does not handle them, as the receiving side always has 0 packets. I cannot see anything being blocked by the firewall, I also tried shuttung down the firewall totally (pfctl -d) without any luck.

      Monitoring enc0 does show the outgoing traffic but nothing coming in, as expected.

      Any idea how I can find out what is happening to those esp packets coming in return?

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.