Hi Tom, Seem to have an issue with my config. If a failover occurs, the firewall detects it and does its job to ''disable'' device. Lsm cannot succesfully ping a outside Ip on failover on the device that comes back up. Here eth0 is up. Yet shorewall eth0 status = 1 eth0 Link encap:Ethernet HWaddr 00:02:B3:D7:B3:C7 inet addr:205.134.193.138 Bcast:205.134.193.143 Mask:255.255.255.248 inet6 addr: fe80::202:b3ff:fed7:b3c7/64 Scope:Link Gate:~ # ping -I 205.134.193.138 4.2.2.2 PING 4.2.2.2 (4.2.2.2) from 205.134.193.138 : 56(84) bytes of data. 64 bytes from 4.2.2.2: icmp_seq=1 ttl=56 time=32.6 ms 64 bytes from 4.2.2.2: icmp_seq=2 ttl=56 time=29.3 ms Here Lsm is not able to ping in its log on verbose. Rea=eth0 May 18 10:45:43 Gate lsm[20982]: name = Com, replied = 100, waiting = 0, timeout = 0, late reply = 0, cons rcvd = 100, cons wait = 0, cons miss = 0, avg_rtt = 31.099, seq = 35330 May 18 10:45:44 Gate lsm[20982]: received seq = 35330 from 4.2.2.1, id = 20981, num_sent = 35330, target id = 1, time_diff = 29471 May 18 10:45:44 Gate lsm[20982]: name = Rea, replied = 0, waiting = 100, timeout = 99, late reply = 0, cons rcvd = 0, cons wait = 100, cons miss = 100, avg_rtt = 0.000, seq = 35332 May 18 10:45:44 Gate lsm[20982]: name = Com, replied = 100, waiting = 0, timeout = 0, late reply = 0, cons rcvd = 100, cons wait = 0, cons miss = 0, avg_rtt = 31.080, seq = 35331 May 18 10:45:45 Gate lsm[20982]: received seq = 35331 from 4.2.2.1, id = 20981, num_sent = 35331, target id = 1, time_diff = 29859 <snip> of shorewall restart Setting up Proxy ARP... Adding Providers... WARNING: Interface eth0 is not usable -- Provider rea (1) not Started Setting up Traffic Control... Preparing iptables-restore input... Gate:~ # shorewall show routing Shorewall 4.5.3.1 Routing at Gate.tituswill.com - Fri May 18 10:48:02 PDT 2012 Routing Rules 0: from all lookup local 999: from all lookup main 1000: from all to 192.168.100.0/24 lookup main 1000: from all to 10.199.7.0/24 lookup main 10001: from all fwmark 0x200/0xff00 lookup com 20000: from 50.78.47.90 lookup com 32765: from all lookup balance 32767: from all lookup default Table balance: default via 50.78.47.94 dev eth1 Table com: 50.78.47.94 dev eth1 scope link src 50.78.47.90 default via 50.78.47.94 dev eth1 src 50.78.47.90 Table default: 205.134.193.137 dev eth0 scope link Table local: local 50.78.47.90 dev eth1 proto kernel scope host src 50.78.47.90 local 205.134.193.138 dev eth0 proto kernel scope host src 205.134.193.138 local 172.16.2.1 dev tun0 proto kernel scope host src 172.16.2.1 local 172.16.100.1 dev tun2 proto kernel scope host src 172.16.100.1 local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 10.20.227.1 dev vlan10 proto kernel scope host src 10.20.227.1 local 10.19.227.20 dev eth3 proto kernel scope host src 10.19.227.20 broadcast 50.78.47.95 dev eth1 proto kernel scope link src 50.78.47.90 broadcast 50.78.47.88 dev eth1 proto kernel scope link src 50.78.47.90 broadcast 205.134.193.143 dev eth0 proto kernel scope link src 205.134.193.138 broadcast 205.134.193.136 dev eth0 proto kernel scope link src 205.134.193.138 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 broadcast 10.20.227.255 dev vlan10 proto kernel scope link src 10.20.227.1 broadcast 10.20.227.0 dev vlan10 proto kernel scope link src 10.20.227.1 broadcast 10.19.227.255 dev eth3 proto kernel scope link src 10.19.227.20 broadcast 10.19.227.0 dev eth3 proto kernel scope link src 10.19.227.20 Table main: 50.78.47.94 dev eth1 scope link src 50.78.47.90 205.134.193.137 dev eth0 scope link src 205.134.193.138 172.16.2.2 dev tun0 proto kernel scope link src 172.16.2.1 172.16.100.2 dev tun2 proto kernel scope link src 172.16.100.1 50.78.47.88/29 dev eth1 proto kernel scope link src 50.78.47.90 205.134.193.136/29 dev eth0 proto kernel scope link src 205.134.193.138 192.168.100.0/24 via 172.16.2.2 dev tun0 10.4.138.0/24 via 10.19.227.254 dev eth3 10.20.227.0/24 dev vlan10 proto kernel scope link src 10.20.227.1 10.199.7.0/24 via 172.16.100.2 dev tun2 10.194.244.0/24 via 10.19.227.254 dev eth3 10.192.139.0/24 via 10.19.227.254 dev eth3 10.19.227.0/24 dev eth3 proto kernel scope link src 10.19.227.20 10.143.99.0/24 via 10.19.227.254 dev eth3 10.10.182.0/24 via 10.19.227.254 dev eth3 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link Gate:~ # ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 5/18/12 10:53 AM, Mike Lander wrote:> Hi Tom, > > Seem to have an issue with my config. > If a failover occurs, the firewall detects it and does its job to ''disable'' > device. > Lsm cannot succesfully ping a outside Ip on failover on the device that > comes back up. > Here eth0 is up. Yet shorewall eth0 status = 1 > > eth0 Link encap:Ethernet HWaddr 00:02:B3:D7:B3:C7 > inet addr:205.134.193.138 Bcast:205.134.193.143 > Mask:255.255.255.248 > inet6 addr: fe80::202:b3ff:fed7:b3c7/64 Scope:Link > > > Gate:~ # ping -I 205.134.193.138 4.2.2.2 > PING 4.2.2.2 (4.2.2.2) from 205.134.193.138 : 56(84) bytes of data. > 64 bytes from 4.2.2.2: icmp_seq=1 ttl=56 time=32.6 ms > 64 bytes from 4.2.2.2: icmp_seq=2 ttl=56 time=29.3 msMike: Use tcpdump to be sure that those pings are actually going out of eth0 and not out of eth1. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Seem to go out right interface but arp trouble Gate:~ # tcpdump -nvi eth0 host 4.2.2.2 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:54:48.908020 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 4.2.2.2 tell 205.134.193.138, length 28 11:54:49.944019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 4.2.2.2 tell 205.134.193.138, length 28 11:54:50.944019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 4.2.2.2 tell 205.134.193.138, length 28 11:54:51.944018 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 4.2.2.2 tell 205.134.193.138, length 28 11:54:52.968019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 4.2.2.2 tell 205.134.193.138, length 28 11:54:53.968037 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 4.2.2.2 tell 205.134.193.138, length 28 11:54:54.968019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 4.2.2.2 tell 205.134.193.138, length 28 ^C 7 packets captured 7 packets received by filter 0 packets dropped by kernel Gate:~ # tcpdump -nvi eth1 4.2.2.2 tcpdump: syntax error Gate:~ # tcpdump -nvi eth1 host 4.2.2.2 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C 0 packets captured 13 packets received by filter 0 packets dropped by kernel Gate:~ # -------- Original Message --------> From: "Tom Eastep" <teastep@shorewall.net> > Sent: Friday, May 18, 2012 11:32 AM > To: shorewall-users@lists.sourceforge.net > Subject: Re: [Shorewall-users] Lsm Failover > > On 5/18/12 10:53 AM, Mike Lander wrote: > > Hi Tom, > > > > Seem to have an issue with my config. > > If a failover occurs, the firewall detects it and does its job to''disable''> > device. > > Lsm cannot succesfully ping a outside Ip on failover on the device that> > comes back up. > > Here eth0 is up. Yet shorewall eth0 status = 1 > > > > eth0 Link encap:Ethernet HWaddr 00:02:B3:D7:B3:C7 > > inet addr:205.134.193.138 Bcast:205.134.193.143 > > Mask:255.255.255.248 > > inet6 addr: fe80::202:b3ff:fed7:b3c7/64 Scope:Link > > > > > > Gate:~ # ping -I 205.134.193.138 4.2.2.2 > > PING 4.2.2.2 (4.2.2.2) from 205.134.193.138 : 56(84) bytes of data. > > 64 bytes from 4.2.2.2: icmp_seq=1 ttl=56 time=32.6 ms > > 64 bytes from 4.2.2.2: icmp_seq=2 ttl=56 time=29.3 ms > > Mike: Use tcpdump to be sure that those pings are actually going out of > eth0 and not out of eth1. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > >---------------------------------------------------------------------------- --> Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions> will include endpoint security, mobile security and the latest in malware> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> Seem to go out right interface but arp trouble > > Gate:~ # tcpdump -nvi eth0 host 4.2.2.2 > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96> bytes > 11:54:48.908020 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 4.2.2.2 tell 205.134.193.138, length 28 > 11:54:49.944019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 4.2.2.2 tell 205.134.193.138, length 28 > 11:54:50.944019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 4.2.2.2 tell 205.134.193.138, length 28 > 11:54:51.944018 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 4.2.2.2 tell 205.134.193.138, length 28 > 11:54:52.968019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 4.2.2.2 tell 205.134.193.138, length 28 > 11:54:53.968037 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 4.2.2.2 tell 205.134.193.138, length 28 > 11:54:54.968019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > 4.2.2.2 tell 205.134.193.138, length 28 > ^C > 7 packets captured > 7 packets received by filter > 0 packets dropped by kernel > Gate:~ # tcpdump -nvi eth1 4.2.2.2 > tcpdump: syntax error > > Gate:~ # tcpdump -nvi eth1 host 4.2.2.2 > tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96> bytes > ^C > 0 packets captured > 13 packets received by filter > 0 packets dropped by kernel > Gate:~ # > > > > -------- Original Message -------- > > From: "Tom Eastep" <teastep@shorewall.net> > > Sent: Friday, May 18, 2012 11:32 AM > > To: shorewall-users@lists.sourceforge.net > > Subject: Re: [Shorewall-users] Lsm Failover > > > > On 5/18/12 10:53 AM, Mike Lander wrote: > > > Hi Tom, > > > > > > Seem to have an issue with my config. > > > If a failover occurs, the firewall detects it and does its job to > ''disable'' > > > device. > > > Lsm cannot succesfully ping a outside Ip on failover on the devicethat> > > > comes back up. > > > Here eth0 is up. Yet shorewall eth0 status = 1 > > > > > > eth0 Link encap:Ethernet HWaddr 00:02:B3:D7:B3:C7 > > > inet addr:205.134.193.138 Bcast:205.134.193.143 > > > Mask:255.255.255.248 > > > inet6 addr: fe80::202:b3ff:fed7:b3c7/64 Scope:Link > > > > > > > > > Gate:~ # ping -I 205.134.193.138 4.2.2.2 > > > PING 4.2.2.2 (4.2.2.2) from 205.134.193.138 : 56(84) bytes of data. > > > 64 bytes from 4.2.2.2: icmp_seq=1 ttl=56 time=32.6 ms > > > 64 bytes from 4.2.2.2: icmp_seq=2 ttl=56 time=29.3 ms > > > > Mike: Use tcpdump to be sure that those pings are actually going outof> > eth0 and not out of eth1. > > > > -TomBut my test is going out eth1 rtt min/avg/max/mdev = 29.114/30.694/32.356/1.172 ms Gate:~ # ping -I 205.134.193.138 4.2.2.2 PING 4.2.2.2 (4.2.2.2) from 205.134.193.138 : 56(84) bytes of data. 64 bytes from 4.2.2.2: icmp_seq=1 ttl=56 time=32.5 ms 64 bytes from 4.2.2.2: icmp_seq=2 ttl=56 time=39.2 ms 64 bytes from 4.2.2.2: icmp_seq=3 ttl=56 time=30.0 ms ^C --- 4.2.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 30.084/33.970/39.253/3.876 ms You have new mail in /var/mail/root Gate:~ # -------------------------------------------dump 0 packets dropped by kernel Gate:~ # tcpdump -nvi eth1 host 4.2.2.2 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 12:05:14.706204 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 50.78.47.90 > 4.2.2.2: ICMP echo request, id 46684, seq 1, length 64 12:05:14.738693 IP (tos 0x20, ttl 56, id 13142, offset 0, flags [none], proto ICMP (1), length 84) 4.2.2.2 > 50.78.47.90: ICMP echo reply, id 46684, seq 1, length 64 12:05:15.705699 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 50.78.47.90 > 4.2.2.2: ICMP echo request, id 46684, seq 2, length 64 Sorry I think I did a top post....Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > Seem to go out right interface but arp trouble > > > > Gate:~ # tcpdump -nvi eth0 host 4.2.2.2 > > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size96> > > bytes > > 11:54:48.908020 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 4.2.2.2 tell 205.134.193.138, length 28 > > 11:54:49.944019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 4.2.2.2 tell 205.134.193.138, length 28 > > 11:54:50.944019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 4.2.2.2 tell 205.134.193.138, length 28 > > 11:54:51.944018 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 4.2.2.2 tell 205.134.193.138, length 28 > > 11:54:52.968019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 4.2.2.2 tell 205.134.193.138, length 28 > > 11:54:53.968037 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 4.2.2.2 tell 205.134.193.138, length 28 > > 11:54:54.968019 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has > > 4.2.2.2 tell 205.134.193.138, length 28 > > ^C > > 7 packets captured > > 7 packets received by filter > > 0 packets dropped by kernel > > Gate:~ # tcpdump -nvi eth1 4.2.2.2 > > tcpdump: syntax error > > > > Gate:~ # tcpdump -nvi eth1 host 4.2.2.2 > > tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size96> > > bytes > > ^C > > 0 packets captured > > 13 packets received by filter > > 0 packets dropped by kernel > > Gate:~ # > > > > > > > > -------- Original Message -------- > > > From: "Tom Eastep" <teastep@shorewall.net> > > > Sent: Friday, May 18, 2012 11:32 AM > > > To: shorewall-users@lists.sourceforge.net > > > Subject: Re: [Shorewall-users] Lsm Failover > > > > > > On 5/18/12 10:53 AM, Mike Lander wrote: > > > > Hi Tom, > > > > > > > > Seem to have an issue with my config. > > > > If a failover occurs, the firewall detects it and does its job to > > ''disable'' > > > > device. > > > > Lsm cannot succesfully ping a outside Ip on failover on the device> that > > > > > > comes back up. > > > > Here eth0 is up. Yet shorewall eth0 status = 1 > > > > > > > > eth0 Link encap:Ethernet HWaddr 00:02:B3:D7:B3:C7 > > > > inet addr:205.134.193.138 Bcast:205.134.193.143 > > > > Mask:255.255.255.248 > > > > inet6 addr: fe80::202:b3ff:fed7:b3c7/64 Scope:Link > > > > > > > > > > > > Gate:~ # ping -I 205.134.193.138 4.2.2.2 > > > > PING 4.2.2.2 (4.2.2.2) from 205.134.193.138 : 56(84) bytes ofdata.> > > > 64 bytes from 4.2.2.2: icmp_seq=1 ttl=56 time=32.6 ms > > > > 64 bytes from 4.2.2.2: icmp_seq=2 ttl=56 time=29.3 ms > > > > > > Mike: Use tcpdump to be sure that those pings are actually going out> of > > > eth0 and not out of eth1. > > > > > > -Tom > But my test is going out eth1 > rtt min/avg/max/mdev = 29.114/30.694/32.356/1.172 ms > Gate:~ # ping -I 205.134.193.138 4.2.2.2 > PING 4.2.2.2 (4.2.2.2) from 205.134.193.138 : 56(84) bytes of data. > 64 bytes from 4.2.2.2: icmp_seq=1 ttl=56 time=32.5 ms > 64 bytes from 4.2.2.2: icmp_seq=2 ttl=56 time=39.2 ms > 64 bytes from 4.2.2.2: icmp_seq=3 ttl=56 time=30.0 ms > ^C > --- 4.2.2.2 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2000ms > rtt min/avg/max/mdev = 30.084/33.970/39.253/3.876 ms > You have new mail in /var/mail/root > Gate:~ # > -------------------------------------------dump > 0 packets dropped by kernel > Gate:~ # tcpdump -nvi eth1 host 4.2.2.2 > tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96> bytes > 12:05:14.706204 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], protoICMP> (1), length 84) > 50.78.47.90 > 4.2.2.2: ICMP echo request, id 46684, seq 1, length 64 > 12:05:14.738693 IP (tos 0x20, ttl 56, id 13142, offset 0, flags [none], > proto ICMP (1), length 84) > 4.2.2.2 > 50.78.47.90: ICMP echo reply, id 46684, seq 1, length 64 > 12:05:15.705699 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], protoICMP> (1), length 84) > 50.78.47.90 > 4.2.2.2: ICMP echo request, id 46684, seq 2, length 64Tom, I entered a ''0'' in /var/lib/eth0.status, restarted shorewall now its all good May 18 12:19:36 Gate lsm[20982]: received seq = 40895 from 4.2.2.1, id = 20981, num_sent = 40895, target id = 1, time_diff = 31504 May 18 12:19:36 Gate lsm[20982]: name = Rea, replied = 12, waiting = 88, timeout = 87, late reply = 0, cons rcvd = 12, cons wait = 0, cons miss = 0, avg_rtt = 41.970, seq = 40897 May 18 12:19:36 Gate lsm[20982]: name = Com, replied = 100, waiting = 0, timeout = 0, late reply = 0, cons rcvd = 100, cons wait = 0, cons miss = 0, avg_rtt = 31.230, seq = 40896 May 18 12:19:36 Gate lsm[20982]: received seq = 40896 from 4.2.2.2, id = 20981, num_sent = 40896, target id = 0, time_diff = 42030 Gate:~ # tcpdump -nvi eth0 host 4.2.2.2 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 12:22:13.472357 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 64) 205.134.193.138 > 4.2.2.2: ICMP echo request, id 62801, seq 23456, length 44 12:22:13.513183 IP (tos 0x0, ttl 56, id 40673, offset 0, flags [none], proto ICMP (1), length 64) 4.2.2.2 > 205.134.193.138: ICMP echo reply, id 62801, seq 23456, length 44 12:22:14.482500 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 64) 205.134.193.138 > 4.2.2.2: ICMP echo request, id 62801, seq 23712, length 44 12:22:14.553295 IP (tos 0x0, ttl 56, id 40674, offset 0, flags [none], proto ICMP (1), length 64) 4.2.2.2 > 205.134.193.138: ICMP echo reply, id 62801, seq 23712, length 44 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 5/18/12 12:27 PM, Mike Lander wrote:> Tom, > I entered a ''0'' in /var/lib/eth0.status, restarted shorewall now its all > good > > > May 18 12:19:36 Gate lsm[20982]: received seq = 40895 from 4.2.2.1, id = > 20981, num_sent = 40895, target id = 1, time_diff = 31504 > May 18 12:19:36 Gate lsm[20982]: name = Rea, replied = 12, waiting = 88, > timeout = 87, late reply = 0, cons rcvd = 12, cons wait = 0, cons miss = 0, > avg_rtt = 41.970, seq = 40897 > May 18 12:19:36 Gate lsm[20982]: name = Com, replied = 100, waiting = 0, > timeout = 0, late reply = 0, cons rcvd = 100, cons wait = 0, cons miss = 0, > avg_rtt = 31.230, seq = 40896 > May 18 12:19:36 Gate lsm[20982]: received seq = 40896 from 4.2.2.2, id = > 20981, num_sent = 40896, target id = 0, time_diff = 42030 > > > Gate:~ # tcpdump -nvi eth0 host 4.2.2.2 > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 > bytes > 12:22:13.472357 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP > (1), length 64) > 205.134.193.138 > 4.2.2.2: ICMP echo request, id 62801, seq 23456, > length 44 > 12:22:13.513183 IP (tos 0x0, ttl 56, id 40673, offset 0, flags [none], > proto ICMP (1), length 64) > 4.2.2.2 > 205.134.193.138: ICMP echo reply, id 62801, seq 23456, length > 44 > 12:22:14.482500 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP > (1), length 64) > 205.134.193.138 > 4.2.2.2: ICMP echo request, id 62801, seq 23712, > length 44 > 12:22:14.553295 IP (tos 0x0, ttl 56, id 40674, offset 0, flags [none], > proto ICMP (1), length 64) > 4.2.2.2 > 205.134.193.138: ICMP echo reply, id 62801, seq 23712, length > 44No it''s not good -- it is just working now until the next failure. Please forward your lsm.conf file and the output of ''shorewall show routing'' with both providers up. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> No it''s not good -- it is just working now until the next failure. > Please forward your lsm.conf file and the output of ''shorewall show > routing'' with both providers up. > > -TomYes I knew not good to go, (still scratching head) lsm 0.130-1 lsm.conf # # (C) 2009 Mika Ilmaranta <ilmis@nullnet.fi> # # License: GPLv2 # # # Debug level: 0 .. 8 are normal, 9 gives lots of stuff and 100 doesn''t # bother to detach # #debug=10 debug=9 #debug=8 # # Defaults for the connection entries # defaults { name=defaults checkip=127.0.0.1 eventscript=/etc/lsm/script notifyscript max_packet_loss=15 max_successive_pkts_lost=7 min_packet_loss=5 min_successive_pkts_rcvd=10 interval_ms=1000 timeout_ms=1000 warn_email=mike@lanlinecomputers.com check_arp=0 sourceip# if using ping probes for monitoring only then defaults should # not define a default device for packets to autodiscover their path # to destination # device=eth0 # use system default ttl ttl=0 # assume initial up state at lsm startup (1 = up, 0 = down, 2 = unknown (default)) # status=1 } # # Some example connections are found in lsm.conf.sample # include /etc/lsm/shorewall.conf #EOF lsm script #!/bin/sh # # (C) 2009 Mika Ilmaranta <ilmis@nullnet.fi> # (C) 2009 Tom Eastep <teastep@shorewall.net> # # License: GPLv2 # STATE=${1} NAME=${2} CHECKIP=${3} DEVICE=${4} WARN_EMAIL=${5} REPLIED=${6} WAITING=${7} TIMEOUT=${8} REPLY_LATE=${9} CONS_RCVD=${10} CONS_WAIT=${11} CONS_MISS=${12} AVG_RTT=${13} if [ -f /usr/share/shorewall-lite/lib.base ]; then VARDIR=/var/lib/shorewall-lite STATEDIR=/etc/shorewall-lite else VARDIR=/var/lib/shorewall STATEDIR=/etc/shorewall fi [ -f ${STATEDIR}/vardir ] && . ${STATEDIR}/vardir cat <<EOM | mail -s "${NAME} ${STATE}, DEV ${DEVICE}" ${WARN_EMAIL} Hi, Connection ${NAME} is now ${STATE}. Following parameters were passed: newstate = ${STATE} name = ${NAME} checkip = ${CHECKIP} device = ${DEVICE} warn_email = ${WARN_EMAIL} Packet counters: replied = ${REPLIED} packets replied waiting = ${WAITING} packets waiting for reply timeout = ${TIMEOUT} packets that have timed out (= packet loss) reply_late = ${REPLY_LATE} packets that received a reply after timeout cons_rcvd = ${CONS_RCVD} consecutively received replies in sequence cons_wait = ${CONS_WAIT} consecutive packets waiting for reply cons_miss = ${CONS_MISS} consecutive packets that have timed out avg_rtt = ${AVG_RTT} average rtt, notice that waiting and timed out packets have rtt = 0 when calculating this Your LSM Daemon EOM if [ ${STATE} = up ]; then # echo 0 > ${VARDIR}/${DEVICE}.status # Uncomment this line if you are running Shorewall 4.4.x or earlier ${VARDIR}/firewall enable ${DEVICE} else # echo 1 > ${VARDIR}/${DEVICE}.status # Uncomment this line if you are running Shorewall 4.4.x or earlier ${VARDIR}/firewall disable ${DEVICE} fi /sbin/shorewall show routing >> /var/log/lsm exit 0 #EOF shorewall show routing Routing Rules 0: from all lookup local 999: from all lookup main 1000: from all to 192.168.100.0/24 lookup main 1000: from all to 10.199.7.0/24 lookup main 10000: from all fwmark 0x100/0xff00 lookup rea 10001: from all fwmark 0x200/0xff00 lookup com 20000: from 205.134.193.138 lookup rea 20000: from 50.78.47.90 lookup com 32765: from all lookup balance 32767: from all lookup default Table balance: default via 50.78.47.94 dev eth1 Table com: 50.78.47.94 dev eth1 scope link src 50.78.47.90 default via 50.78.47.94 dev eth1 src 50.78.47.90 Table default: 205.134.193.137 dev eth0 scope link default via 205.134.193.137 dev eth0 src 205.134.193.138 metric 1 Table local: local 50.78.47.90 dev eth1 proto kernel scope host src 50.78.47.90 local 205.134.193.138 dev eth0 proto kernel scope host src 205.134.193.138 local 172.16.2.1 dev tun0 proto kernel scope host src 172.16.2.1 local 172.16.100.1 dev tun2 proto kernel scope host src 172.16.100.1 local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 10.20.227.1 dev vlan10 proto kernel scope host src 10.20.227.1 local 10.19.227.20 dev eth3 proto kernel scope host src 10.19.227.20 broadcast 50.78.47.95 dev eth1 proto kernel scope link src 50.78.47.90 broadcast 50.78.47.88 dev eth1 proto kernel scope link src 50.78.47.90 broadcast 205.134.193.143 dev eth0 proto kernel scope link src 205.134.193.138 broadcast 205.134.193.136 dev eth0 proto kernel scope link src 205.134.193.138 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 broadcast 10.20.227.255 dev vlan10 proto kernel scope link src 10.20.227.1 broadcast 10.20.227.0 dev vlan10 proto kernel scope link src 10.20.227.1 broadcast 10.19.227.255 dev eth3 proto kernel scope link src 10.19.227.20 broadcast 10.19.227.0 dev eth3 proto kernel scope link src 10.19.227.20 Table main: 50.78.47.94 dev eth1 scope link src 50.78.47.90 205.134.193.137 dev eth0 scope link src 205.134.193.138 172.16.2.2 dev tun0 proto kernel scope link src 172.16.2.1 172.16.100.2 dev tun2 proto kernel scope link src 172.16.100.1 50.78.47.88/29 dev eth1 proto kernel scope link src 50.78.47.90 205.134.193.136/29 dev eth0 proto kernel scope link src 205.134.193.138 192.168.100.0/24 via 172.16.2.2 dev tun0 10.4.138.0/24 via 10.19.227.254 dev eth3 10.20.227.0/24 dev vlan10 proto kernel scope link src 10.20.227.1 10.199.7.0/24 via 172.16.100.2 dev tun2 10.194.244.0/24 via 10.19.227.254 dev eth3 10.192.139.0/24 via 10.19.227.254 dev eth3 10.19.227.0/24 dev eth3 proto kernel scope link src 10.19.227.20 10.143.99.0/24 via 10.19.227.254 dev eth3 10.10.182.0/24 via 10.19.227.254 dev eth3 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link Table rea: 205.134.193.137 dev eth0 scope link src 205.134.193.138 default via 205.134.193.137 dev eth0 src 205.134.193.138 Gate:~ # ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 05/18/2012 12:51 PM, Mike Lander wrote:> > > >> No it''s not good -- it is just working now until the next failure. >> Please forward your lsm.conf file and the output of ''shorewall show >> routing'' with both providers up. >> >> -Tom > > Yes I knew not good to go, (still scratching head) > lsm 0.130-1 > lsm.conf > # > # (C) 2009 Mika Ilmaranta<ilmis@nullnet.fi> > # > # License: GPLv2 > # > > # > # Debug level: 0 .. 8 are normal, 9 gives lots of stuff and 100 doesn''t > # bother to detach > # > #debug=10 > debug=9 > #debug=8 > > # > # Defaults for the connection entries > # > defaults { > name=defaults > checkip=127.0.0.1 > eventscript=/etc/lsm/script > notifyscript> max_packet_loss=15 > max_successive_pkts_lost=7 > min_packet_loss=5 > min_successive_pkts_rcvd=10 > interval_ms=1000 > timeout_ms=1000 > warn_email=mike@lanlinecomputers.com > check_arp=0 > sourceip> # if using ping probes for monitoring only then defaults should > # not define a default device for packets to autodiscover their path > # to destination > # device=eth0 > # use system default ttl > ttl=0 > # assume initial up state at lsm startup (1 = up, 0 = down, 2 = unknown > (default)) > # status=1 > } > > # > # Some example connections are found in lsm.conf.sample > # > include /etc/lsm/shorewall.confSorry -- also need to see that file. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > > Yes I knew not good to go, (still scratching head) > > lsm 0.130-1 > > lsm.conf > > # > > # (C) 2009 Mika Ilmaranta<ilmis@nullnet.fi> > > # > > # License: GPLv2 > > # > > > > # > > # Debug level: 0 .. 8 are normal, 9 gives lots of stuff and 100doesn''t> > # bother to detach > > # > > #debug=10 > > debug=9 > > #debug=8 > > > > # > > # Defaults for the connection entries > > # > > defaults { > > name=defaults > > checkip=127.0.0.1 > > eventscript=/etc/lsm/script > > notifyscript> > max_packet_loss=15 > > max_successive_pkts_lost=7 > > min_packet_loss=5 > > min_successive_pkts_rcvd=10 > > interval_ms=1000 > > timeout_ms=1000 > > warn_email=mike@lanlinecomputers.com > > check_arp=0 > > sourceip> > # if using ping probes for monitoring only then defaults should > > # not define a default device for packets to autodiscover their path > > # to destination > > # device=eth0 > > # use system default ttl > > ttl=0 > > # assume initial up state at lsm startup (1 = up, 0 = down, 2 =unknown> > (default)) > > # status=1 > > } > > > > # > > # Some example connections are found in lsm.conf.sample > > # > > include /etc/lsm/shorewall.conf > > Sorry -- also need to see that file. > > -Tom > --shorewall.conf in lsm directory connection { name=Rea checkip=4.2.2.2 device=eth0 ttl=64 } connection { name=Com checkip=4.2.2.1 device=eth1 ttl=64 } Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 05/18/2012 01:02 PM, Mike Lander wrote:>>> >>> Yes I knew not good to go, (still scratching head) >>> lsm 0.130-1 >>> lsm.conf >>> # >>> # (C) 2009 Mika Ilmaranta<ilmis@nullnet.fi> >>> # >>> # License: GPLv2 >>> # >>> >>> # >>> # Debug level: 0 .. 8 are normal, 9 gives lots of stuff and 100 > doesn''t >>> # bother to detach >>> # >>> #debug=10 >>> debug=9 >>> #debug=8 >>> >>> # >>> # Defaults for the connection entries >>> # >>> defaults { >>> name=defaults >>> checkip=127.0.0.1 >>> eventscript=/etc/lsm/script >>> notifyscript>>> max_packet_loss=15 >>> max_successive_pkts_lost=7 >>> min_packet_loss=5 >>> min_successive_pkts_rcvd=10 >>> interval_ms=1000 >>> timeout_ms=1000 >>> warn_email=mike@lanlinecomputers.com >>> check_arp=0 >>> sourceip>>> # if using ping probes for monitoring only then defaults should >>> # not define a default device for packets to autodiscover their path >>> # to destination >>> # device=eth0 >>> # use system default ttl >>> ttl=0 >>> # assume initial up state at lsm startup (1 = up, 0 = down, 2 > unknown >>> (default)) >>> # status=1 >>> } >>> >>> # >>> # Some example connections are found in lsm.conf.sample >>> # >>> include /etc/lsm/shorewall.conf >> >> Sorry -- also need to see that file. >> >> -Tom >> -- > shorewall.conf in lsm directory > > connection { > name=Rea > checkip=4.2.2.2 > device=eth0 > ttl=64 > } > > connection { > name=Com > checkip=4.2.2.1 > device=eth1 > ttl=64 > } > MikeOkay. You need to use your distribution''s network configuration facilities to add a route to 4.2.2.2/32 via the default gateway on eth0 and a route to 4.2.2.1/32 via the default gateway on eth1. It''s important that traffic to the ''checkip'' address be routed out of the correct interface even when that interface is unusable. That''s the only way that LSM can determine when the interface comes back up. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > Yes I knew not good to go, (still scratching head) > > lsm 0.130-1 > > lsm.conf > > # > > # (C) 2009 Mika Ilmaranta<ilmis@nullnet.fi> > > # > > # License: GPLv2 > > # > > > > # > > # Debug level: 0 .. 8 are normal, 9 gives lots of stuff and 100doesn''t> > # bother to detach > > # > > #debug=10 > > debug=9 > > #debug=8 > > > > # > > # Defaults for the connection entries > > # > > defaults { > > name=defaults > > checkip=127.0.0.1 > > eventscript=/etc/lsm/script > > notifyscript> > max_packet_loss=15 > > max_successive_pkts_lost=7 > > min_packet_loss=5 > > min_successive_pkts_rcvd=10 > > interval_ms=1000 > > timeout_ms=1000 > > warn_email=mike@lanlinecomputers.com > > check_arp=0 > > sourceip> > # if using ping probes for monitoring only then defaults should > > # not define a default device for packets to autodiscover their path > > # to destination > > # device=eth0 > > # use system default ttl > > ttl=0 > > # assume initial up state at lsm startup (1 = up, 0 = down, 2 =unknown> > (default)) > > # status=1 > > } > > > > # > > # Some example connections are found in lsm.conf.sample > > # > > include /etc/lsm/shorewall.conf > > Sorry -- also need to see that file. > > -TomI also might add this incase of any bearing on trouble here. I was up late testing this more so if comcast failed. It seem to have the same issue, ie lsm cant ping its downsteam ip when disable is in effect in shorewall. This morning a live real failure occured on the failover isp.(rea) I had forgot to stop lsm last night. They called and woke me up complaining the ipsec tunnel was down. When it failed I had modifed lsm in the way below when it failed live. (may not have any bearing on trouble not sure) #!/bin/sh # # (C) 2009 Mika Ilmaranta <ilmis@nullnet.fi> # (C) 2009 Tom Eastep <teastep@shorewall.net> # # License: GPLv2 # STATE=${1} NAME=${2} CHECKIP=${3} DEVICE=${4} WARN_EMAIL=${5} REPLIED=${6} WAITING=${7} TIMEOUT=${8} REPLY_LATE=${9} CONS_RCVD=${10} CONS_WAIT=${11} CONS_MISS=${12} AVG_RTT=${13} if [ -f /usr/share/shorewall-lite/lib.base ]; then VARDIR=/var/lib/shorewall-lite STATEDIR=/etc/shorewall-lite else VARDIR=/var/lib/shorewall STATEDIR=/etc/shorewall fi [ -f ${STATEDIR}/vardir ] && . ${STATEDIR}/vardir cat <<EOM | mail -s "${NAME} ${STATE}, DEV ${DEVICE}" ${WARN_EMAIL} Hi, Connection ${NAME} is now ${STATE}. Following parameters were passed: newstate = ${STATE} name = ${NAME} checkip = ${CHECKIP} device = ${DEVICE} warn_email = ${WARN_EMAIL} Packet counters: replied = ${REPLIED} packets replied waiting = ${WAITING} packets waiting for reply timeout = ${TIMEOUT} packets that have timed out (= packet loss) reply_late = ${REPLY_LATE} packets that received a reply after timeout cons_rcvd = ${CONS_RCVD} consecutively received replies in sequence cons_wait = ${CONS_WAIT} consecutive packets waiting for reply cons_miss = ${CONS_MISS} consecutive packets that have timed out avg_rtt = ${AVG_RTT} average rtt, notice that waiting and timed out packets have rtt = 0 when calculating this Your LSM Daemon EOM if [ ${STATE} = up ]; then # echo 0 > ${VARDIR}/${DEVICE}.status # Uncomment this line if you are running Shorewall 4.4.x or earlier ${VARDIR}/firewall enable ${DEVICE} else # echo 1 > ${VARDIR}/${DEVICE}.status # Uncomment this line if you are running Shorewall 4.4.x or earlier ${VARDIR}/firewall disable ${DEVICE} /usr/sbin/ipsec stop /usr/sbin/openvpn stop fi /sbin/shorewall show routing >> /var/log/lsm exit 0 #EOF Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> On 05/18/2012 01:02 PM, Mike Lander wrote: > >>> > >>> Yes I knew not good to go, (still scratching head) > >>> lsm 0.130-1 > >>> lsm.conf > >>> # > >>> # (C) 2009 Mika Ilmaranta<ilmis@nullnet.fi> > >>> # > >>> # License: GPLv2 > >>> # > >>> > >>> # > >>> # Debug level: 0 .. 8 are normal, 9 gives lots of stuff and 100 > > doesn''t > >>> # bother to detach > >>> # > >>> #debug=10 > >>> debug=9 > >>> #debug=8 > >>> > >>> # > >>> # Defaults for the connection entries > >>> # > >>> defaults { > >>> name=defaults > >>> checkip=127.0.0.1 > >>> eventscript=/etc/lsm/script > >>> notifyscript> >>> max_packet_loss=15 > >>> max_successive_pkts_lost=7 > >>> min_packet_loss=5 > >>> min_successive_pkts_rcvd=10 > >>> interval_ms=1000 > >>> timeout_ms=1000 > >>> warn_email=mike@lanlinecomputers.com > >>> check_arp=0 > >>> sourceip> >>> # if using ping probes for monitoring only then defaults should > >>> # not define a default device for packets to autodiscover their path > >>> # to destination > >>> # device=eth0 > >>> # use system default ttl > >>> ttl=0 > >>> # assume initial up state at lsm startup (1 = up, 0 = down, 2 > > unknown > >>> (default)) > >>> # status=1 > >>> } > >>> > >>> # > >>> # Some example connections are found in lsm.conf.sample > >>> # > >>> include /etc/lsm/shorewall.conf > >> > >> Sorry -- also need to see that file. > >> > >> -Tom > >> -- > > shorewall.conf in lsm directory > > > > connection { > > name=Rea > > checkip=4.2.2.2 > > device=eth0 > > ttl=64 > > } > > > > connection { > > name=Com > > checkip=4.2.2.1 > > device=eth1 > > ttl=64 > > } > > Mike > > Okay. > > You need to use your distribution''s network configuration facilities > to add a route to 4.2.2.2/32 via the default gateway on eth0 and a > route to 4.2.2.1/32 via the default gateway on eth1. > > It''s important that traffic to the ''checkip'' address be routed out of > the correct interface even when that interface is unusable. That''s the > only way that LSM can determine when the interface comes back up. > > -Tom > --Tom, Makes perfect sense. I was not aware of that. Thank you, Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Tom, I have one last question about this, I noticed that in your config. You use the default gateway of your ISP''s. Many times I have had various isp''s fail. I ping the default gateway as a test. 99% of the gateway replies, because they are static. Then I try something downstream and of course its down. In your case does your failover work because its dhcp? And your default gate is not active in your comcast modem? The reason I ask is originally I had entered the next downstream hop on both these ISPs when I started testing. I used the common open dns servers as a last resort last night. (4.2.2.2) (They always answer pings.) Since I now know that lsm did not have the correct routes > inferface, this has been my trouble. Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 05/18/2012 02:08 PM, Mike Lander wrote:> Tom, > I have one last question about this, I noticed that in your config. You use > the default gateway of your ISP''s. > Many times I have had various isp''s fail. I ping the default gateway as a > test. 99% of the gateway replies, > because they are static. Then I try something downstream and of course its > down. > In your case does your failover work because its dhcp? And your default > gate is not active in your comcast modem? > > The reason I ask is originally I had entered the next downstream hop on > both these ISPs when I started > testing. I used the common open dns servers as a last resort last night. > (4.2.2.2) (They always answer pings.) > Since I now know that lsm did not have the correct routes> inferface, this > has been my trouble.Mike, My configuration has changed quite a bit since I published that article. Then, the default gateway was at the provider''s facility and not local. Now my default gateway is local on one uplink so I ping the next hop router and use TTL=2 on that provider. The problems I have encountered are almost always between my house and the provider, so doing it that is adequate and there are always the proper routes in place. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> On 05/18/2012 02:08 PM, Mike Lander wrote: > > Tom, > > I have one last question about this, I noticed that in your config. Youuse> > the default gateway of your ISP''s. > > Many times I have had various isp''s fail. I ping the default gateway asa> > test. 99% of the gateway replies, > > because they are static. Then I try something downstream and of courseits> > down. > > In your case does your failover work because its dhcp? And yourdefault> > gate is not active in your comcast modem? > > > > The reason I ask is originally I had entered the next downstream hopon> > both these ISPs when I started > > testing. I used the common open dns servers as a last resort lastnight.> > (4.2.2.2) (They always answer pings.) > > Since I now know that lsm did not have the correct routes> inferface,this> > has been my trouble. > > > Mike, > > My configuration has changed quite a bit since I published that article.> Then, the default gateway was at the provider''s facility and not local. > Now my default gateway is local on one uplink so I ping the next hop > router and use TTL=2 on that provider. The problems I have encountered > are almost always between my house and the provider, so doing it that is> adequate and there are always the proper routes in place. > > -Tom > --Hi Tom, The failover worked last night. However this morning with tcpoutgoiung empty. Squid was requesting pages through my failover ISP ''rea'' in this case. I entered tcpgoing= to fix it for now. After re-reading. I have changed restore defaultroute=No and changed providers. Right now I think squids cache is fooling me so I will leave this for awhile and check tonight. before changes #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY rea 1 256 - eth0 205.134.193.137 fallback com 2 512 - eth1 50.78.47.94 New config I am trying>shorewall show routing is with the provider config here #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY rea 1 256 - eth0 205.134.193.137 loose,fallback com 2 512 - eth1 50.78.47.94 balance Gate:~ # shorewall show routing Shorewall 4.5.3.1 Routing at Gate.tituswill.com - Sat May 19 13:32:25 PDT 2012 Routing Rules 0: from all lookup local 999: from all lookup main 1000: from all to 192.168.100.0/24 lookup main 1000: from all to 10.199.7.0/24 lookup main 10000: from all fwmark 0x100/0xff00 lookup rea 10001: from all fwmark 0x200/0xff00 lookup com 20000: from 50.78.47.90 lookup com 32765: from all lookup balance 32767: from all lookup default Table balance: default via 50.78.47.94 dev eth1 Table com: 50.78.47.94 dev eth1 scope link src 50.78.47.90 default via 50.78.47.94 dev eth1 src 50.78.47.90 Table default: 205.134.193.137 dev eth0 scope link default via 205.134.193.137 dev eth0 src 205.134.193.138 metric 1 Table local: local 50.78.47.90 dev eth1 proto kernel scope host src 50.78.47.90 local 205.134.193.138 dev eth0 proto kernel scope host src 205.134.193.138 local 172.16.2.1 dev tun0 proto kernel scope host src 172.16.2.1 local 172.16.100.1 dev tun2 proto kernel scope host src 172.16.100.1 local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 10.20.227.1 dev vlan10 proto kernel scope host src 10.20.227.1 local 10.19.227.20 dev eth3 proto kernel scope host src 10.19.227.20 broadcast 50.78.47.95 dev eth1 proto kernel scope link src 50.78.47.90 broadcast 50.78.47.88 dev eth1 proto kernel scope link src 50.78.47.90 broadcast 205.134.193.143 dev eth0 proto kernel scope link src 205.134.193.138 broadcast 205.134.193.136 dev eth0 proto kernel scope link src 205.134.193.138 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 broadcast 10.20.227.255 dev vlan10 proto kernel scope link src 10.20.227.1 broadcast 10.20.227.0 dev vlan10 proto kernel scope link src 10.20.227.1 broadcast 10.19.227.255 dev eth3 proto kernel scope link src 10.19.227.20 broadcast 10.19.227.0 dev eth3 proto kernel scope link src 10.19.227.20 Table main: 73.98.6.1 via 50.78.47.94 dev eth1 50.78.47.94 dev eth1 scope link src 50.78.47.90 205.134.212.1 via 205.134.193.137 dev eth0 205.134.193.137 dev eth0 scope link src 205.134.193.138 172.16.2.2 dev tun0 proto kernel scope link src 172.16.2.1 172.16.100.2 dev tun2 proto kernel scope link src 172.16.100.1 50.78.47.88/29 dev eth1 proto kernel scope link src 50.78.47.90 205.134.193.136/29 dev eth0 proto kernel scope link src 205.134.193.138 192.168.100.0/24 via 172.16.2.2 dev tun0 10.4.138.0/24 via 10.19.227.254 dev eth3 10.20.227.0/24 dev vlan10 proto kernel scope link src 10.20.227.1 10.199.7.0/24 via 172.16.100.2 dev tun2 10.194.244.0/24 via 10.19.227.254 dev eth3 10.192.139.0/24 via 10.19.227.254 dev eth3 10.19.227.0/24 dev eth3 proto kernel scope link src 10.19.227.20 10.143.99.0/24 via 10.19.227.254 dev eth3 10.10.182.0/24 via 10.19.227.254 dev eth3 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link Table rea: 205.134.193.137 dev eth0 scope link src 205.134.193.138 default via 205.134.193.137 dev eth0 src 205.134.193.138 You have new mail in /var/mail/root Gate:~ # ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
My bad had a half finished entry in tcrules...Sorry Mike ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 05/19/2012 09:01 PM, Mike Lander wrote:> My bad had a half finished entry in tcrules...Sorry >No problem. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/