Navigation

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

    Not being able to connect to a CISCO ASA on PfSense

    IPsec
    1
    1
    120
    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.
    • M
      masterkorp last edited by

      Hello Everyone,

      I have a IPSec Connection (Policy Based) that I have full connectiviy over.

      Traffic can flow both sides, But can't set any service to actually receive traffic.

      [21.02.2-RELEASE][root@renx-vpn-pf.eastus2.cloudapp.azure.com]/home/Alfredo: ipsec statusall
      Status of IKE charon daemon (strongSwan 5.9.1, FreeBSD 12.2-STABLE, amd64):
        uptime: 19 hours, since May 19 15:01:51 2021
        worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
        loaded plugins: charon unbound pkcs11 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 unity counters
      Listening IP addresses:
        10.0.7.4
        10.200.1.1
      Connections:
            bypass:  %any...127.0.0.1  IKEv1/2
            bypass:   local:  uses any authentication
            bypass:   remote: uses any authentication
         con100000:  10.0.7.4...23.235.122.4  IKEv2
         con100000:   local:  [123.123.123.123] uses pre-shared key authentication
         con100000:   remote: [23.235.122.4] uses pre-shared key authentication
         con100000:   child:  123.123.123.123/32|10.0.7.0/24 === 456.456.456.456/32|/0 789.789.789.789/32|/0 TUNNEL
      Routed Connections:
         con100000{1}:  ROUTED, TUNNEL, reqid 1
         con100000{1}:   123.123.123.123/32|10.0.7.0/24 === 789.789.789.789/32|/0 456.456.456.456/32|/0
      Security Associations (1 up, 0 connecting):
         con100000[1]: ESTABLISHED 19 hours ago, 10.0.7.4[123.123.123.123]...23.235.122.4[23.235.122.4]
         con100000[1]: IKEv2 SPIs: bed5641258955b9f_i* f86da67c5f546b5b_r, rekeying in 80 minutes
         con100000[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
         con100000{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c920018d_i a846b411_o
         con100000{7}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 76260 bytes_o (615 pkts, 9s ago), rekeying in 22 minutes
         con100000{7}:   123.123.123.123/32|10.0.7.0/24 === 456.456.456.456/32|/0
         con100000{8}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cdf000a1_i 1e13d2c7_o
         con100000{8}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 1116 bytes_o (9 pkts, 9s ago), rekeying in 42 minutes
         con100000{8}:   123.123.123.123/32|10.0.7.0/24 === 456.456.456.456/32|/0
         con100000{9}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cc153fea_i c5d1190d_o
         con100000{9}:  AES_CBC_256/HMAC_SHA2_256_128, 39012 bytes_i (770 pkts, 36s ago), 20956 bytes_o (169 pkts, 20789s ago), rekeying in 66 minutes
         con100000{9}:   123.123.123.123/32|10.0.7.0/24 === 789.789.789.789/32|/0
         con100000{10}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: cb6b904c_i 8f51621a_o
         con100000{10}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 622604 bytes_o (5021 pkts, 9s ago), rekeying in 74 minutes
         con100000{10}:   123.123.123.123/32|10.0.7.0/24 === 456.456.456.456/32|/0
      

      So I can telnet the other side of the with something like telnet 456.456.456.456 15502 and we get a successful connection.

      But if I do and nc -l 15502 and a telnet from the other side we never get a connection. All firewall rules are open on the ipsec tunnel now. But on a traffic capture I can see the TCP Packet incomming when I do a packet capture.
      Screenshot from 2021-05-20 11-57-49.png

      I dont really have any more Ideas, everything is open on the firewall rules, maybe its because the service does not know what interface to bind to since its this connection does not create an interface?

      Thank you for any help!

      1 Reply Last reply Reply Quote 0
      • First post
        Last post