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

IPSec VPN with PSK - traffic going out unencrypted

Hi,

We are currently setting up VPN connections to a number of carriers, and we are having trouble with one of them.

The tunnel is up between the particular carrier and ourselves, and I can see the expected VPN Route. Phase 1 and 2 seem to have succeeded. The problem is that the carrier is saying that they are seeing 0 packets delivered over the tunnel, but they are seeing unencrypted packets hitting their firewall, which their firewall is dropping. We are trying to Telnet to their host system on the specified port, but cannot get anywhere, as their firewall is dropping all packets from us.

I have mirrored the port of the interface connected to our DSL router and have run a packet sniffer on the port. It appears that the carrier is correct and that these packets are leaving the firewall unencrypted.

Is there any way to see exactly how individual packets are being routed through the ASL, i.e. some log file somewhere.

My concern is that if a route, such as a VPN route exists in the firewall, surely it will try that route first. However it seems to just be sending it out the default interface, not out of the secure tunnel.

Please let me know what logs/configs you will need to see in order to provide further help.

Thanks and regards,

Nick


This thread was automatically locked due to age.
Parents
  • Hi,

    go to the console, and use eg. tcpdump -i ipsec0. There you schould see your IPSEC traffic in clear text, because you grab inside the tunnel. If you make the same on eg. tcpdump -i eth0 (possible your external interface) you only should see the traffic encrpyted (ESP traffic).

    If you see it in clear text, than you have trouble with associating the packet with the vpn tunnel. Mostly this is cause by a wrong target subnet. 

    Can you post your tunnel config.

    Chris
  • Hi all,

    Thanks for your responses.

    This one turned out to be a problem with the fact that 'Strict Routing' was turned on for that tunnel, and there was a mismatch on the source IP  (strict routing checks both source and destination IP), thereby causing traffic to be sent out the default route - DSL interface, rather than going down the tunnel.

    Once again, thanks for all your responses and help.

    Regards,

    Nick.
Reply
  • Hi all,

    Thanks for your responses.

    This one turned out to be a problem with the fact that 'Strict Routing' was turned on for that tunnel, and there was a mismatch on the source IP  (strict routing checks both source and destination IP), thereby causing traffic to be sent out the default route - DSL interface, rather than going down the tunnel.

    Once again, thanks for all your responses and help.

    Regards,

    Nick.
Children
No Data