Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 451 views
  • Users 0 members are here
Options
Suggested
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

ASL 4.x IPSEC Net-to-Net issue

JeffBrownlee
Scenerio:

IPSEC Net to Net - ASL 4.018

192.168.0.0/16 internet --- internet 192.168.234.0/24

Problem is that when the IPSEC tunnel is brought up, I lose the ability to ping, and/or talk to the internal interface on the 192.168.234.0 side from that subnet whatsoever.  I am able to communicate with it from the remote end (with its internal 234.1 ip) however.  (NOTE: the firewall still routes traffic fine, it just isn't responsive to traffic intended for its internal interface)

When the tunnel is brought down, all communications on the 234 side to the firewall work fine (able to webadmin, ping, etc the internal interface).   This problem does not show up when the /24 side of the tunnel is running ASL 2.x.

It would seem there is an issue with routing in 4.x that leads ASL to ignore the fact that the /24 netmask is more granular than the /16 that was not present in the 2.x versions of ASL.

Anyone experienced this or have any idea as to why it is happening?  


This thread was automatically locked due to age.
  • 0
    check the VPN routes and the static routes on the remote side, maybe when the VPN tunnel is up, the wrong route loads and the traffic for 234.1 goes to the remote lan instead of the internal IF 
  • 0 in reply to Guillermo Lovato
    >> check the VPN routes and the static routes on the remote side, maybe when the VPN tunnel is up, the wrong route loads and the traffic for 234.1 goes to the remote lan instead of the internal IF

    234 only exists on this node, and is routed back correctly (since local machines can talk to the remote network fine, just not the internal interface of the local firewall).  From the remote end, connecting to 234.1 via https or ssh does in fact create a connection to the firewall as well.  Problem seems to be that packets destined for the local subnet are routed over the ipsec tunnel as part of the /16 (completely ignoring the more granular 234.0/24 interface route)  
Cookie Information Banner