Guest User!

You are not Sophos Staff.

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

remote VPN access vs. multilink

wyocowboy
We are using ASG 8.3 We have had PPTP VPN working (yes, we will be going with a more secure method soon) back when we had a single DSL internet link. We now have a second cable internet link from a second ISP and have multilink configured with the cable as primary and DSL as standby. Each link has an IP address associated with the respective ISP. Multilink is working as expected: if the primary link goes down, it activates the backup link and vice versa.

Since going with the multilink, remote VPN will not work when using the IP associated with the cable link, which is active most of the time, and at the time of my testing. Wireshark on the client computer shows that ASG is issuing a TCP Reset in response to each frame that is sent by the client. 

As a test, I disabled the interface in ASG associated with the cable connection and this forced the DSL link to become active. I then addressed the VPN client to the IP associated with that interface and it worked.

I looked through the various webadmin options and the manual and don't see anything that would be causing this problem. Am I missing something, or is this a known issue?

Thanks.


This thread was automatically locked due to age.
Parents
  • 0
    No, it wasn't you, but I've been accused of it!

    My guess would be that the same driver works for multiple chipsets. From being on the other side of the fence, hardware vendors strive for that - less work. I don't see any layer1/2 problems that I would expect with a wrong driver scenario. We have seen some outages flagged by ASG on the cable link, but that was caused by a routing loop issue on the ISP side that cause the TTL on the link monitoring pings to expire in transit. 

    L2TP/IPSec doesn't seem to work either; gets an ICMP port 500 unreachable. I can imagine the scenario where the kernel, packet forwarding/firewall portions are ok with the new NIC, but if the correct entries did not get populated as a result of the after-the-fact NIC install, other code modules might not be, so I'll try the reinstall this weekend.

    What vintage of config backup would you recommend; one that predates the new NIC?
Reply
  • 0
    No, it wasn't you, but I've been accused of it!

    My guess would be that the same driver works for multiple chipsets. From being on the other side of the fence, hardware vendors strive for that - less work. I don't see any layer1/2 problems that I would expect with a wrong driver scenario. We have seen some outages flagged by ASG on the cable link, but that was caused by a routing loop issue on the ISP side that cause the TTL on the link monitoring pings to expire in transit. 

    L2TP/IPSec doesn't seem to work either; gets an ICMP port 500 unreachable. I can imagine the scenario where the kernel, packet forwarding/firewall portions are ok with the new NIC, but if the correct entries did not get populated as a result of the after-the-fact NIC install, other code modules might not be, so I'll try the reinstall this weekend.

    What vintage of config backup would you recommend; one that predates the new NIC?
Children
No Data