New answers tagged

2

Try to add this line in /etc/network/interfaces pre-down ip route change default via 10.255.255.1 dev eth0 src 82.82.82.82


0

When multiple VPNs connect in random order, their interface IDs change. Therefor the normal ROUTE -P ADD 10.0.0.0 MASK 255.255.0.0 10.0.0.1 IF 42 does not work. The next time the VPN connects it might have a different interface number. Powershell has a cmdlet available that adds routes on VPN connection and removes them again when the VPN is disconnected: ...


0

When multiple VPNs connect in random order, their interface IDs change. Therefor the normal ROUTE -P ADD 10.0.0.0 MASK 255.255.0.0 10.0.0.1 IF 42 does not work. The next time the VPN connects it might have a different interface number. Powershell has a cmdlet available that adds routes on VPN connection and removes them again when the VPN is disconnected: ...


4

When Red Hat's networking scripts set multiple IPv6 addresses configured in /etc/sysconfig/network-scripts/ifcfg-*, for whatever reason, they are applied in reverse order, so that the last address listed in IPV6ADDR_SECONDARIES becomes the address used by default for outgoing connections. Reversing the order in which IPv6 addresses are listed is generally ...


0

It seems like the iptables input table rules do not allow ESP packets. You could try adding "iptables -A INPUT -p esp -j ACCEPT" to iptables.


1

Imagine a system with 1 physical adapter: enp2s0. It's routing table might start out as all traffic goes out enp2s0. Once the system connects to a VPN, a TUN interface (tun0) is initialized and the VPN updates the routing table: All traffic destined to VPN server address on port X (VPN server address and port) goes out enp2s0. All other traffic goes ...


1

With destination based routing it's not hard either. The way I usually see is to load a route to the VPN server specifying the pre-existing gateway and interface and distance (really routing priority) set to 1. The VPN's default route would always have a distance of at least 2.


4

You are correct that with purely destination-based routing this is a problem, if the destinations you are reaching through the tunnel overlap with routing needed for tunnel establishment, etc.... The way I have usually seen this done, and done it myself on various routers, is to use policy routing : The router acting as a VPN endpoint keeps its default ...


0

Judging by "onboot" I'm guessing it's Centos/Fedora/RedHat server. Try doing something like this. Edit eth5 config file: /etc/sysconfig/network-scripts/ifcfg-eth5 and leave only one line in there: DEVICE=eth5 and restart network service. After that eth5 want have any IP address assigned.


0

At last the issue resolved with tuning the branch router TCP ADJUST MSS of the tunnel. Go to the tunnel in config mode and execute tcp adjust mss 1250. the default is 1450. Then the webmail is working fine from branch.



Top 50 recent answers are included