This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ESPDUMP like the UTM has?

Has anyone come across a way to view packets inside of encap IPsec traffic?  On the UTM firewalls, it's as simple as using espdump -n --conn 'REF_TunnelName' and it shows the decapsulated inner packets.  This is a must have on the XG.  Trying to troubleshoot any traffic inside the tunnel on the XG doesn't seem possible or that easy.

 

Ideas?



This thread was automatically locked due to age.
Parents
  • In the current build, there is no ESPDUMP, so you cannot see, what is going on in the tunnel.

    But: You can see the traffic in the tunnel with the packetcapture tool in the webadmin. 

    Also important to know: You see in the tcpdump the outgoing ipsec traffic, not incoming. 

    tbh - espdump is not "that easy". If you try to dump the esp into file and read it in wireshark, it gets really messy. 

  • I understand about tcpdump and opening in Wireshark using the SPD/SPI file and passing in the PSK.  What I like about ESPDUMP on the UTM is that it does all that for you, on the fly.  The tcpdump build in XG doesn't even support the nflog interface.  It only shows incoming packets in the ipsec0 interface, not outgoing.

    Currently I have an IPSEC tunnel to a customer who has some ridiculous requirements.  They didn't want us to use our RFC1918 addresses and gave us some of their public IP addresses to NAT to in the tunnel.  That is done and works great, but now I need to MASQ (SNAT) a small group of our servers as a single server on our side, I have tried everything, and it doesn't appear to be working.  I wanted to look inside the ESP payload to see if the NAT was being applied, etc.

    Tunnel config

    Local Subnet (Public IPs from customer)
    1.2.3.4
    1.2.3.5
    1.2.3.6

    NAT (to RFC1928)
    1.2.3.4 to 172.2.3.4
    1.2.3.5 to 172.2.3.5
    1.2.3.6 to 172.2.3.6

    The situation is that they have a set of servers on their side (Domain Controllers) that only allows traffic from our Domain Controllers, nothing else.  We have a AD trust to their domain and I have 2 remote desktop servers that need to make UDP/389 calls to their domain controller (seen via Wireshark capture) when they log in.  I need to MASQ those RPD servers (port 389 only) as our domain controller(s), which is already NATed in the tunnel.  I setup a Firewall rule, with traffic selectors and a NAT/Masq policy.  I then did a ‘system ipsec_route add’ via CLI to route into the tunnel.  I’ve been wanting to see if things are applying properly, ESP dump would be fabulous here.

    It’s unfortunate that XG is the new child and development seems to have stalled on UTM.  That really is superior to XG.

  • This kind of config should work fine. 

    As far as i can tell, i have done this many times.

    Can you post screenshots / mapping of those NATs? 

    System ipsec route will only handle the system only.

    So basically you would perform the NAT like above and create a firewall rule only allowing RDP from IP to IP without NAT. Die NAT will be performed in the Iptables by the Ipsec rules itself. Not by the firewall Policies.

Reply
  • This kind of config should work fine. 

    As far as i can tell, i have done this many times.

    Can you post screenshots / mapping of those NATs? 

    System ipsec route will only handle the system only.

    So basically you would perform the NAT like above and create a firewall rule only allowing RDP from IP to IP without NAT. Die NAT will be performed in the Iptables by the Ipsec rules itself. Not by the firewall Policies.

Children
No Data