Jerry Vonau wrote: > On Fri, 2009-01-09 at 10:32 -0600, John McMonagle wrote: > >> Have a firewall with 2 isps, openvpn, ipsec and ospf in use. >> The ospf is primarily for the openvpn tunnels. >> I'm phasing out ipsec because of traffic shaping issues. >> >> Been rereading http://www.shorewall.net/MultiISP.html and realize I >> probably have a couple things not right. >> >> in Table 200 are a few hacks to fix a couple problems. >> ip route list table 200 >> # iax routing mentioned next. >> 192.168.11.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets >> via ipsec use local net ip instead of isp1 >> 192.168.10.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets >> via ipsec use local net ip instead of isp1 >> >> > 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. > > 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 :-) 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. So the real point is to force the source ip for locally originating traffic. I suppose it could be 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 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 :-( > >> 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. 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. 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 :-) 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. 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?? >> 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 :-( 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
