Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 463 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

IPSEC won't establish with NAT traversal asg v7 to v8.2

BSavage
I upgraded our hub firewall terminating 34 tunnels initiated from v7.509 asg's, and only had 30 of 34 tunnels establish. I noticed the 4 that wouldn't establish were using nat traversal across another router(FIOS router or Linksys WRT54g). No matter what I tried, I couldn't get the tunnel to establish. These tunnels were esstablished on 8.103 prior to the v8.2 upgrade. I reverted back to 8.103 to resolve the issue.

Brian


This thread was automatically locked due to age.
Parents
  • 0
    I'm on 8.201 after having other issues with 8.1x, and now there's no remote access with NATted clients, using L2TP or PPTP--both of which worked swimmingly under 8.1x and 7.x before that.
  • 0 in reply to MillardJK
    Well, it's still the case that L2TP won't connect, but I've managed to get PPTP to connect.

    But it won't route, at least not with a split tunnel. For the way I've got it configured--and how it worked fine before 8.02--when a PPTP connection is established, a Win7 client will have an address issued by the local DHCP host (putting it 'on net' with the rest of the inside network, eliminating the routing unknowns) instead of using the PPTP pool. In that case, the ASG erroneously publishes the default route for the connection as the PPTP adapter, and there's no route to it from the local machine.

    When I change to using the PPTP pool, the gateway doesn't change, but the local PPTP address is now in the same subnet. I can ping "across" the gap, but because there's no route, I can't get to the remote network. If I manually add a static route for the client (route add remote.network mask net.mask pptp.gateway), it should route correctly, but it doesn't. Logging on to the SSH console of the ASG, the local route table shows the PPTP client via ppp0, but you can't ping the client.

    This is really annoying, and not the first time that I've run into remote access issues with new versions. I'm really beginning to wonder how much QA is being done after they update the remote access code.

    Now I've got to figure out if I've got a 8.1x backup available so that I can revert using an ISO...
Reply
  • 0 in reply to MillardJK
    Well, it's still the case that L2TP won't connect, but I've managed to get PPTP to connect.

    But it won't route, at least not with a split tunnel. For the way I've got it configured--and how it worked fine before 8.02--when a PPTP connection is established, a Win7 client will have an address issued by the local DHCP host (putting it 'on net' with the rest of the inside network, eliminating the routing unknowns) instead of using the PPTP pool. In that case, the ASG erroneously publishes the default route for the connection as the PPTP adapter, and there's no route to it from the local machine.

    When I change to using the PPTP pool, the gateway doesn't change, but the local PPTP address is now in the same subnet. I can ping "across" the gap, but because there's no route, I can't get to the remote network. If I manually add a static route for the client (route add remote.network mask net.mask pptp.gateway), it should route correctly, but it doesn't. Logging on to the SSH console of the ASG, the local route table shows the PPTP client via ppp0, but you can't ping the client.

    This is really annoying, and not the first time that I've run into remote access issues with new versions. I'm really beginning to wonder how much QA is being done after they update the remote access code.

    Now I've got to figure out if I've got a 8.1x backup available so that I can revert using an ISO...
Children
No Data