Jerry Vonau wrote: > >> My question are not about net 192.168.11.0/24 and 192.168.10.0/24 routing. >> These are both via ipsec without ospf ( static ) and being phased out. >> It fixes an odd ipsec routing problem that is supposedly "impossible" >> to fix :-) >> Without this rule: >> Traffic from 192.168.2.0/23 routes fine. >> Traffic from firewall will have source ip of 69.129.223.178 not >> 192.168.2.254 and traffic can not return via the same ipsec tunnel. >> > > That is the above route in table 200, right? > > ipsec stuff is 2 of the 3 routes in table 200
> >>>> The primary thing that is getting my attention is iax traffic will not >>>> pass from 192.168.3.1 to 192.168.1.15 >>>> >>>> >>> Yea, the traffic from 192.168.3.1 would have a route in the main table >>> while the route to 192.168.1.0/24 via 172.17.2.2 is in table 200 >>> >>> >> Table 200 gets checked first >> >> # ip rule >> 0: from all lookup local >> 200: from all lookup 200 >> 10000: from all fwmark 0x100 lookup ISP1 >> 10001: from all fwmark 0x200 lookup ISP2 >> 20000: from 69.129.223.178 lookup ISP1 >> 20001: from 69.129.223.179 lookup ISP1 >> 20002: from 69.129.223.180 lookup ISP1 >> 20003: from 69.129.223.181 lookup ISP1 >> 20256: from 24.196.120.30 lookup ISP2 >> 32766: from all lookup main >> 32767: from all lookup default >> >> > > Yes, it does, but table 200 doesn't have a route to handle 192.168.3.1, > so the traffic doesn't get to use the gateway, as there is no route in > that table. > Another odd one. you may not have noticed the the local network is 192.168.2.0/23 that includes 192.168.3.1. I needed more room and expanded the subnet. I would really like to break down the subnet sizes wanted to avoid putting a lot of static routes everywhere. After I get ospf working everywhere I'll probably start splitting up that network. > >> Did a little looking in connection tracking: >> show connections | grep 192.168.1.15 >> udp 17 33 src=192.168.2.12 dst=192.168.1.15 sport=47824 dport=161 >> packets=12 bytes=2520 src=192.168.1.15 dst=192.168.2.12 sport=161 >> dport=47824 packets=12 bytes=3747 [ASSURED] mark=0 secmark=0 use=1 >> udp 17 179 src=192.168.1.15 dst=192.168.3.1 sport=4569 dport=4569 >> packets=88918 bytes=17416041 src=192.168.3.1 dst=192.168.1.15 sport=4569 >> dport=1063 packets=71166 bytes=15442677 [ASSURED] mark=0 secmark=0 use=1 >> udp 17 138 src=192.168.3.1 dst=192.168.1.15 sport=4569 dport=4569 >> packets=468312 bytes=81679406 src=192.168.1.15 dst=24.196.120.30 >> sport=4569 dport=4569 packets=428620 bytes=76092029 [ASSURED] mark=512 >> secmark=0 use=1 >> >> On the last line the second dst dst=24.196.120.30 should be >> dst=192.168.1.15 >> >> That is what keeps the routing messed up. The question is what caused it >> to nat out isp2 in the first place. >> >> > Yea, traffic from 192.168.3.1 got marked, because there is no route to > the remote subnet. OK there is, but traffic can't use it, there is no > route in table 200 for 192.168.2.0/23 > > Again isn't 192.168.3.1 in 192.168.2.0/23 And back to the real point 192.168.1.0/24 via 172.17.2.2 dev tun1 proto zebra metric 70 in table main should have done it. Did aging with ssh running from 192.168.3.1 > 192.168.1.15 r...@fonroute:/etc/shorewall# shorewall show connections | grep 192.168.1.15 tcp 6 431961 ESTABLISHED src=192.168.3.1 dst=192.168.1.15 sport=52177 dport=22 packets=21 bytes=2928 src=192.168.1.15 dst=192.168.3.1 sport=22 dport=52177 packets=20 bytes=3508 [ASSURED] mark=0 secmark=0 use=1 udp 17 172 src=192.168.3.1 dst=192.168.1.15 sport=4569 dport=4569 packets=469256 bytes=81717166 src=192.168.1.15 dst=24.196.120.30 sport=4569 dport=4569 packets=429092 bytes=76110909 [ASSURED] mark=512 secmark=0 use=1 I took some lines out. ssh wants to go the correct way. >> Or just go to USE_DEFAULT_RT=Yes? >> If I'm reading correcly ospf and USE_DEFAULT_RT=No is going to break at >> some point?? >> >> > If ospf plays with the default gateways, yes things break, even if you > use USE_DEFAULT_RT=Yes > > ospf doesn't touch the default route or local interface 192.168.2.0/23 I'll try USE_DEFAULT_RT=Yes this weekend and see what happens. Thanks for the input. John -- John McMonagle IT Manager Advocap Inc. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
