On Fri, 2009-01-09 at 14:37 -0600, John McMonagle wrote: > Jerry Vonau wrote: > > On Fri, 2009-01-09 at 10:32 -0600, John McMonagle wrote: > >
> > Example 2 on the MultiIsp page shows that the routes would be in the > > main table and "rouing rules" are used to force the lookup to use the > > main table. > > > > You have a route to both 192.168.10.x 192.168.11.x using eth1 in the > > main table but no via gateway and no ipaddress assigned to eth1 in those > > ranges. Those routes are then being copied to that provider's table. > > Sorry, just didn't quite look right to me, and that is not the source of your issue. > > Shouldn't those routes be in the main table or is there something with > > zebra that I'm missing? > > > > > I only mentioned what was in table 200 because it is a bit odd. > Was trying to explain them so we could get to the problem. > Guess I messed that up :-) Not really, I would of asked what was up with table 200 anyway, 192.168.1.0/24 via 172.17.2.2 dev tun1 is your main issue. > 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? > So the real point is to force the source ip for locally originating > traffic. > I suppose it could be in the main table. > I try to use the KISS (Keep It Simple Stupid) method, I'd leave it in the main table. > >> 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. > Wanted to give dump but people need to make calls so I needed to include it. > Without that static route phone calls stop, people are angry. > Removing that route is my primary immediate goal. > > > >> All icmp ssh etc works OK. Really strange. > >> The rule "192.168.1.0/24 via 172.17.2.2 dev tun1" makes it work but > >> besides not being correct I want to add redundant openvpn tunnels and > >> the static route must go. > >> > >> > > That is not a routing rule, it a static route, try "ip rule ls" is see a > > routing rule. > > > > Sorry meant route :-( No problem, > > > >> This is shorewall version 4.2.1. I recently changed from 4.0 to fix some > >> traffic shaping issues and it did not have this problem. > >> > >> Is there any way to test if packets are marked? > >> > > > > "shorewall show mangle" but I don't see you using the tcrules file, so > > I'm unsure of what you mean by "marked" > > > > > That gives the rules. > I would like to see what packets are marked. > apparently tcp dump can not test marks. > About all I can think of it to put in a log entry in rules. > That might be helpful. > Hope I'm getting this right.. > If I understand correctly how the packets get routed back to the > correct isp is as they come back from the local network the connection > tracking tables are checked for what isp they belong to. They are > marked uniquely for each isp. > ip rules are set up for each mark and sent to the appropriate routing rules. s/b ip rules are set up for each mark and sent to the appropriate routing table > As I recall really only need for dnat. > Or do the 2000x routing rule do that directly? > I remember setting this up myself a long time ago. > I sort of recall having to mark packets for dnat to work. > A lot easier to have Tom keep track of the fine points :-) > 1000x ip rules handle the inbound for dnat, and entries in tcrules. 2000x ip rules handle the outbound from the firewall > 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 > 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 > > >> My guess is that some how these packets are being marked and going to > >> table ISP2. > >> > >> > > I'll guess that the packets are being dropped as there is no route for > > the traffic. > > > They try to nat via isp2 most of the time. > Most interoffice traffic is going via isp1 the odds are real high it > will go via isp2 > > > > Jerry > > > > > > > Any how thanks for the try. > Sorry if I my descriptions are poor. > I'm not best writer :-( Me either, I wasn't clear on what to do with the static route for tun1. I'd try to add a route to table 200 for the 192.168.2.0/23 subnet, or move that static route to the main table and add a route_rule for the traffic as in my prior email. Hope it helps, Jerry ------------------------------------------------------------------------------ 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 Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
