remote VPN access vs. multilink

Hi, Do you have any MultiPath rules setup?

Barry

I think you may have run into a bug, so I hope you can have your reseller submit a support request.  I'm not much of a fan of failover mode as a similar effect occurs with multipathing.  Multipath mode works much better with VPNs and Mail Security, so I second Barry's implication...

Try changing your Uplink Balancing mode, and then using Multipath rules to bind specific traffic to a specific interface.  The trick here is that Multipath rules only can determine the interface used for outbound traffic; inbound traffic targets are determined by the sender.  We rarely use PPTP, so I don't know that this will avoid the bug (my guess) you're seeing, but I guess it might; it works fine with L2TP over IPsec.

Cheers - Bob

I do not have any multipath rules set up. We are stuck with PPTP at the moment because the DSL modem is operating in DMZ mode and L2TP over IPsec doesn't seem to like the NAT aspect of that. We are supposed to be getting fiber after that ISP gets it to our side of the gorge, so both interfaces should be directly addressable at that point.

I agree that it looks like a bug, but in the meantime I need a workaround, so I'll try playing with the multipath rules.

I tried a multipath rule and no luck. The rule pointed all VPN protocols from Any to dest = cable internet interface/network. As a workaround, I also tried taking the DSL out of standby, making it active and it now will not respond at all to the PPTP initiation request; with or without a multipath rule. Bottom line: the only way I have been able to get this to work is if I disable the cable internet link.

I think I was confused about where the client was, but I understand now that your client computer was outside your network and is calling the IP of the primary link.  That should work!

In the multipath rule, the traffic selector would be something like: 'Uplink Interfaces -> {Services group with PPTP & GRE} -> Internet'.  You should be able to use "Any" instead of "Uplink Interfaces" there.

Cheers - Bob

Yes, roaming users are trying to connect to the corporate network through ASG via PPTP VPN. After further testing, it appears that the issue has nothing to do with multilink. If I disable uplink balancing, the multipath rule and disable the DSL interface ASG still returns a TCP reset to each packet when I try to connect via PPTP. Before I did that, I tried a multipath rule that had Any -> VPN Protocols (built in service group) -> Internet and got the same results.

I suspect that there is a persistent setting or automatically created rule that I can't get to that is associating VPN with the original internet link.  

I don't know if it is related or not, but ASG acted weird back when I added the second WAN NIC; when it booted up, it would not pass any traffic through the old NIC until I assigned an IP address to the new NIC (even though it was not connected). If that particular 'feature' is by design, it isn't a friendly one. I never reported it because I got past it and it was working (except for VPN).

Wait a minute - you added a NIC without reloading the software?  The Astaro O/S is not plug-n-play - unless the new NIC is identical to one of the existing NICs, it shouldn't work at all.

I haven't experienced the issue you're having.  Try reloading from CDROM and restoring the configuration, and let us know if the problem is resolved.

Cheers - Bob

??? What generation of *nix kernel is it built on? Every distro I've played with for the past few years is PnP (OpenSuse, Red Hat, Knoppix, Ubuntu, CentOS, Debian). Anyways, like most distros, the ASG correctly identified the new NIC, loaded the driver and it works, with the exception of PPTP VPN on the new NIC. That doesn't sound like an kernel problem to me.

I appreciate your suggestion, but I'm not going to reload the OS. We are moving away from Astaro anyways, and I've already spent too much time on this. As a side note, I followed up on your statement about L2TP/IPSec and tried that as well. ASG returns ICMP port 500 unreachable. I still need some sort of VPN working until we can replace ASG, so I'll play with that in the meantime; sounds like it is missing a rule or two.

Depending on the brand of the NIC, there might be a generational difference enough to cause this issue.  You might be able to band-aid this by lowering the MTU and/or setting the NIC to a fixed speed at half- or full-duplex.

Astaro never has been PnP.  That's because the kernal has been stripped of anything unnecessary in order to "harden" it.  I'm sorry your reseller never communicated that to you.  A reload can be accomplished in 10-15 minutes.  Put an unencrypted backup of the config in the root of a USB memory stick, reload the OS from CDROM and then reboot the Astaro with the USB memory stick in place.

Cheers - Bob

[I'm not trying to be argumentative here, and I appreciate your help. Just trying to understand. Most of my experience has been with routers, network engineering (design a simulation of the internet that fits in a room) and engineering/systems QA. Part of that involved analyzing packet captures, so I use Wireshark and such whenever something doesn't work]

I haven't seen any sort of issue with the new NIC. It syncs up with the cable modem @ 1GB/full and the speed tests show ~30mbps down. Real world usage confirms that this link is much faster than the DSL. I don't see how a driver issue would cause it to return TCP resets only to PPTP packets. We are able to come into that interface using MS RDP and Webadmin with no problems and performance is noticably snappier there as well.

FWIW, ASG has identified the new NIC as a Realtek with a different chipset than the other two. I realize that ASG is stripped down, but if it is not PnP I don't see how it would have detected and loaded a driver for the new NIC. It should have done nothing at all in that case.

If adding additional NICs or any other hardware after the initial installation is a no-no, it would have been nice to see that in the documentation. The reseller hasn't had any prior experience with the software version of ASG, so I don't know that he would have caught that either.