If I am configured for multi-isp routing with track and balance and using tcrules to force all originating traffic out one of the interfaces rather than really load balancing them and then if I have an openvpn tunnel that goes (down and then back) up it seems the ISP specific routing tables lose the openvpn added route and therefore try to route via the default interface.
i.e. # ip route ls table CGCO 24.226.1.121 dev eth1 scope link 72.38.184.1 dev eth1 scope link src 72.38.184.236 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 192.168.0.0/24 via 10.75.22.137 dev eth0 proto zebra 10.75.22.0/24 dev eth0 proto kernel scope link src 10.75.22.254 10.75.23.0/24 via 10.33.66.2 dev tun0 192.168.154.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 172.16.235.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 72.38.184.0/23 dev eth1 proto kernel scope link src 72.38.184.236 169.254.0.0/16 dev eth1 scope link default via 72.38.184.1 dev eth1 10.75.23.0/24 via 10.33.66.2 dev tun0 is a route through openvpn. Now I stop openvpn: # ip route ls table CGCO 24.226.1.121 dev eth1 scope link 72.38.184.1 dev eth1 scope link src 72.38.184.236 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 192.168.0.0/24 via 10.75.22.137 dev eth0 proto zebra 10.75.22.0/24 dev eth0 proto kernel scope link src 10.75.22.254 192.168.154.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 172.16.235.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 72.38.184.0/23 dev eth1 proto kernel scope link src 72.38.184.236 169.254.0.0/16 dev eth1 scope link default via 72.38.184.1 dev eth1 10.75.23.0/24 route is gone. Not surprising. Now restart openvpn: # ip route ls table CGCO 24.226.1.121 dev eth1 scope link 72.38.184.1 dev eth1 scope link src 72.38.184.236 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 192.168.0.0/24 via 10.75.22.137 dev eth0 proto zebra 10.75.22.0/24 dev eth0 proto kernel scope link src 10.75.22.254 192.168.154.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 172.16.235.0/24 via 10.75.22.1 dev eth0 proto zebra metric 20 72.38.184.0/23 dev eth1 proto kernel scope link src 72.38.184.236 169.254.0.0/16 dev eth1 scope link default via 72.38.184.1 dev eth1 The result of this is (tcpdump on eth1) of course: 00:07:01.643348 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 601, length 64 00:07:02.642972 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 602, length 64 00:07:03.643018 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 603, length 64 00:07:04.643082 IP 10.75.22.1 > 10.75.23.254: ICMP echo request, id 29246, seq 604, length 64 and of course the ping is failing. And if I add the route back manually... # ip route add 10.75.23.0/24 via 10.33.66.2 dev tun0 table CGCO like magic, pinging is working again. None of this is really all that surprising. I'm just wondering what others are doing to solve it. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
