I''m in the early stages of replacing a linux based router and VPN server and I''m hoping to get some suggestions on the best way to implement it using Shorewall. I''ve used Shorewall before on a half dozen routers and I can work my way through the man pages and howtos. I just don''t wish to start off with the wrong strategy. Router has two ethernet i/f''s, eth0 connected to the Internet and eth1 connected to a tagged VLAN fiber backbone. Zone''s - corporate - VLAN2 and VLAN3 - two subnets to different buildings with routing between them. Default gateway for the corporate WAN is a router on VLAN2. - industrial - VLAN4 and VLAN5 - two subnets to different buildings with routing between them. - internet - PopTop pptpd server on router so that outside systems (limited by an extensive ACL) can connect to the industrial zone. Also a ssh server protected by the same ACL. No communication between corporate and industrial zones required but it might be nice to be able to reach the time server on the DC on VLAN2 from the industrial zone. I think I could do that with DNAT. Dhcp relay running on the router to relay dhcp requests from VLAN3 to the DC on VLAN2. The system that we are replacing used to be the main NAT router to the Internet for the corporate side. As such it has it''s default gateway on the Internet and a large routing table to direct anything on the corporate side out via the WAN router. This is a pain to maintain. I''d rather have the WAN router be the default. I guess the question is how do I have any incoming connections (pptpd and ssh) on the Internet i/f route back out to the gateway on the internet side. It''s like a dual homed router (which I have done before) but I don''t want to load balance. I just want any incoming connections from the internet zone to the firewall to use the gateway on the internet. It would also be good if any ip request originating from the router to any ip address outside of the directly connected networks or explicitly defined in the routing table to use the internet GW as it''s default. Another way of putting the problem is I need any routing requests for the default gw from systems on the corporate zone to use one target and any requests for the default gw originating on the firewall itself to use a different target. Thanks in advance for your help. ------------------------------------------------------------------------------ The Next 800 Companies to Lead America''s Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev
On 11/6/10 2:06 PM, Alan Madill wrote:> I''m in the early stages of replacing a linux based router and VPN server and I''m > hoping to get some suggestions on the best way to implement it using Shorewall. > I''ve used Shorewall before on a half dozen routers and I can work my way through > the man pages and howtos. I just don''t wish to start off with the wrong strategy. > > Router has two ethernet i/f''s, eth0 connected to the Internet and eth1 connected > to a tagged VLAN fiber backbone. > > Zone''s > - corporate - VLAN2 and VLAN3 - two subnets to different buildings with routing > between them. Default gateway for the corporate WAN is a router on VLAN2. > - industrial - VLAN4 and VLAN5 - two subnets to different buildings with routing > between them. > - internet - PopTop pptpd server on router so that outside systems (limited by > an extensive ACL) can connect to the industrial zone. Also a ssh server > protected by the same ACL. > > No communication between corporate and industrial zones required but it might be > nice to be able to reach the time server on the DC on VLAN2 from the industrial > zone. I think I could do that with DNAT. > > Dhcp relay running on the router to relay dhcp requests from VLAN3 to the DC on > VLAN2. > > The system that we are replacing used to be the main NAT router to the Internet > for the corporate side. As such it has it''s default gateway on the Internet and > a large routing table to direct anything on the corporate side out via the WAN > router. This is a pain to maintain. I''d rather have the WAN router be the default. >If your routing environment is that complex, then: a) Shorewall will never be a solution to your problem. b) You need to implement a routing protocol internally. -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 \________________________________________________ ------------------------------------------------------------------------------ The Next 800 Companies to Lead America''s Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev
On 11/6/2010 6:20 PM, Tom Eastep wrote:> On 11/6/10 2:06 PM, Alan Madill wrote: >> >> The system that we are replacing used to be the main NAT router to the Internet >> for the corporate side. As such it has it''s default gateway on the Internet and >> a large routing table to direct anything on the corporate side out via the WAN >> router. This is a pain to maintain. I''d rather have the WAN router be the default. >> > If your routing environment is that complex, then: > > a) Shorewall will never be a solution to your problem. > b) You need to implement a routing protocol internally. > > -TomI understand point a) but I''m not quite sure what you mean by point b). I don''t have a complete grasp of the netfilter layer but can''t you tag (or mark) packets based on origin (or other criteria) and then run them through a unique routing table? Is this how the dual homed router or the decision to send a given port (say smtp) out through a given interface on a dual homed router works? If point a) is correct then you have just saved me a lot of "bang head against desk" repeat, repeat,... Thank you. ------------------------------------------------------------------------------ The Next 800 Companies to Lead America''s Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev
On 11/6/10 8:29 PM, Alan Madill wrote:> > > On 11/6/2010 6:20 PM, Tom Eastep wrote: >> On 11/6/10 2:06 PM, Alan Madill wrote: >>> >>> The system that we are replacing used to be the main NAT router to the Internet >>> for the corporate side. As such it has it''s default gateway on the Internet and >>> a large routing table to direct anything on the corporate side out via the WAN >>> router. This is a pain to maintain. I''d rather have the WAN router be the default. >>> >> If your routing environment is that complex, then: >> >> a) Shorewall will never be a solution to your problem. >> b) You need to implement a routing protocol internally. >> >> -Tom > > I understand point a) but I''m not quite sure what you mean by point b). > > I don''t have a complete grasp of the netfilter layer but can''t you tag (or mark) > packets based on origin (or other criteria) and then run them through a unique > routing table?Yes -- but something (someone) needs to populate that routing table.> Is this how the dual homed router or the decision to send a > given port (say smtp) out through a given interface on a dual homed router works?Dual homing almost never involves multiple routing tables. It rather uses a single routing table to determine where to send packets.> > If point a) is correct then you have just saved me a lot of "bang head against > desk" repeat, repeat,... Thank you. >If your gateway has multiple *default* routes, then Shorewall can insure that response packets will be send via the appropriate default route (one default route per routing table -- a default route may have multiple next hops). But it cannot do "This request came from VLAN4 so the response will be routed back through VLAN4" without routing help. VLANs are are virtual ethernet LANs -- the destination of every packet send to the VLAN must be specified by a unique layer 2 (MAC) address (exceptions are broadcast and multicast). -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 \________________________________________________ ------------------------------------------------------------------------------ The Next 800 Companies to Lead America''s Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev
On 11/6/2010 9:02 PM, Tom Eastep wrote:> > VLANs are are virtual ethernet LANs -- the destination of every packet > send to the VLAN must be specified by a unique layer 2 (MAC) address > (exceptions are broadcast and multicast). >I''m having an issue with pptpd (Poptop) server on the firewall/router. It is not responding to arp requests for the ppp0 connection. interfaces net eth0 detect tcpflags,nosmurfs corp eth1.2 detect dhcp,tcpflags,logmartians corp eth1.3 detect dhcp,tcpflags,logmartians proc eth1.4 detect tcpflags,logmartians proc eth1.5 detect tcpflags,logmartians vpn ppp+ rules (didn''t use tunnels) $PPTPIP is a list of clients defined in params # Replaces entry in tunnels with ACL ACCEPT net:$PPTPIP $FW tcp 1723 ACCEPT $FW net 47 ACCEPT net:$PPTPIP $FW 47 pptpd.conf localip 10.1.19.1 remoteip 10.1.19.248-253 options.pptpd proxyarp Client can connect, can ping router ip, can ping ppp0 address, tcpdump shows pings leaving the interface but all we see are arp requests from the target asking for the mac. ping from remote system (vpn client) to host on vlan 4 (ppp0 - 10.1.19.248, eth1.4 - 10.1.19.1) # tcpdump -ni eth1.4 host 10.1.19.248 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1.4, link-type EN10MB (Ethernet), capture size 96 bytes 16:51:05.602191 IP 10.1.19.248 > 10.1.19.4: ICMP echo request, id 1280, seq 256, length 40 16:51:05.602337 arp who-has 10.1.19.248 tell 10.1.19.4 16:51:10.895146 IP 10.1.19.248 > 10.1.19.4: ICMP echo request, id 1280, seq 512, length 40 16:51:10.895327 arp who-has 10.1.19.248 tell 10.1.19.4 The echo request is leaving the interface but the router is making no attempt to reply to the who-has requests. tcpdump of the arp traffic during ping from remote client. # tcpdump -ni eth1.4 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1.4, link-type EN10MB (Ethernet), capture size 96 bytes 17:02:48.622219 arp who-has 10.1.19.4 tell 10.1.19.1 17:02:48.622367 arp reply 10.1.19.4 is-at 00:0e:0c:af:86:3b 17:02:48.622536 arp who-has 10.1.19.248 tell 10.1.19.4 17:02:53.871295 arp who-has 10.1.19.248 tell 10.1.19.4 .... arping from another host on the same subnet # arping -I eth0.4 10.1.19.248 ARPING 10.1.19.248 from 10.1.19.254 eth0.4 Sent 7 probes (7 broadcast(s)) Received 0 response(s) tcpdump while the arping was happening [root@platlnxrtr2 shorewall]# tcpdump -ni eth1.4 host 10.1.19.248 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1.4, link-type EN10MB (Ethernet), capture size 96 bytes 16:53:57.843136 arp who-has 10.1.19.248 (Broadcast) tell 10.1.19.254 16:53:58.844487 arp who-has 10.1.19.248 (Broadcast) tell 10.1.19.254 16:53:59.846334 arp who-has 10.1.19.248 (Broadcast) tell 10.1.19.254 16:54:00.848172 arp who-has 10.1.19.248 (Broadcast) tell 10.1.19.254 arp table on router # arp -an ? (xxx.xxx.xxx.xxx) at 00:10:18:90:20:DB [ether] on eth0 ? (10.1.19.254) at 00:13:46:61:B9:4B [ether] on eth1.4 ? (10.1.16.2) at 00:26:B9:8D:8A:F1 [ether] on eth1.2 ? (10.1.16.19) at 00:17:31:88:3D:22 [ether] on eth1.2 ? (10.1.19.248) at * PERM PUP on eth1.4 from /var/log/messages pppd[13753]: MPPE 128-bit stateless compression enabled pppd[13753]: found interface eth1.4 for proxy arp pppd[13753]: local IP address 10.1.19.1 pppd[13753]: remote IP address 10.1.19.248 It works just fine with this basic config. # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination PPP-INPUT all -- anywhere anywhere RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination PPP-INPUT all -- anywhere anywhere RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain PPP-INPUT (2 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:pptp ACCEPT gre -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere ACCEPT ah -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT tcp -- anywhere anywhere tcp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh REJECT all -- anywhere anywhere reject-with icmp-host-prohibited I know - ACCEPT all -- anywhere anywhere - is bad. # tcpdump -ni eth1.4 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1.4, link-type EN10MB (Ethernet), capture size 96 bytes 17:10:22.656250 arp who-has 10.1.19.4 tell 10.1.19.1 17:10:22.656390 arp reply 10.1.19.4 is-at 00:0e:0c:af:86:3b 17:10:22.656557 arp who-has 10.1.19.248 tell 10.1.19.4 17:10:23.295331 arp reply 10.1.19.248 is-at 00:19:b9:33:2f:18 So it has something to do with the shorewall config ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev
On 11/11/10 5:21 PM, Alan Madill wrote:> > > On 11/6/2010 9:02 PM, Tom Eastep wrote: >> >> VLANs are are virtual ethernet LANs -- the destination of every packet >> send to the VLAN must be specified by a unique layer 2 (MAC) address >> (exceptions are broadcast and multicast). >> > I''m having an issue with pptpd (Poptop) server on the firewall/router. It is > not responding to arp requests for the ppp0 connection.Thank you for all of the information; unfortunately it won''t help us solve the problem. Shorewall itself cannot *directly* affect ARP. It configures iptables/Netfilter which only operates on IP, not ARP (or Appletalk, or ...). So we need different information: a) The output of ''shorewall dump'' with a configuration that works (not necessarily a Shorewall-generated configuration). b) The output of ''shorewall dump'' with a configuration that does not work. c) What you are doing to test; what you did, what you expected to happen, what actually happened. And please note this quote from http://www.shorewall.net/support.htm (you did visit that page before reporting your problem, right?): "Please do NOT include the output of "iptables -L" - the output of ''shorewall show'' or ''shorewall dump'' is much more useful to us." Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev
On 11/11/2010 6:21 PM, Tom Eastep wrote:> On 11/11/10 5:21 PM, Alan Madill wrote: >> >> On 11/6/2010 9:02 PM, Tom Eastep wrote: >>> VLANs are are virtual ethernet LANs -- the destination of every packet >>> send to the VLAN must be specified by a unique layer 2 (MAC) address >>> (exceptions are broadcast and multicast). >>> >> I''m having an issue with pptpd (Poptop) server on the firewall/router. It is >> not responding to arp requests for the ppp0 connection. > Thank you for all of the information; unfortunately it won''t help us > solve the problem. Shorewall itself cannot *directly* affect ARP. It > configures iptables/Netfilter which only operates on IP, not ARP (or > Appletalk, or ...).But it does play with a lot of different parameters, modules, sysctl, etc that can impact ARP.> So we need different information: > > a) The output of ''shorewall dump'' with a configuration that works (not > necessarily a Shorewall-generated configuration). > b) The output of ''shorewall dump'' with a configuration that does not work. > c) What you are doing to test; what you did, what you expected to > happen, what actually happened. >Attached - with the shorewall and the simple home-brew configs. The previous message has the details. With shorewall the router/pptpd server does not respond to ARP requests for the proxyarp entry for the client end of the pppd link, 10.1.19.248 on eth1.4.> And please note this quote from http://www.shorewall.net/support.htm > (you did visit that page before reporting your problem, right?): > > "Please do NOT include the output of "iptables -L" - the output of > ''shorewall show'' or ''shorewall dump'' is much more useful to us." > > Thanks, > -Tom > > > ------------------------------------------------------------------------------ > Centralized Desktop Delivery: Dell and VMware Reference Architecture > Simplifying enterprise desktop deployment and management using > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end > client virtualization framework. Read more! > http://p.sf.net/sfu/dell-eql-dev2dev > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev
On 11/12/10 9:45 AM, Alan Madill wrote:> > > On 11/11/2010 6:21 PM, Tom Eastep wrote: >> Shorewall itself cannot *directly* affect ARP. It >> configures iptables/Netfilter which only operates on IP, not ARP (or >> Appletalk, or ...). > > But it does play with a lot of different parameters, modules, sysctl, > etc that can impact ARP.One key piece of information that was omitted is that your Shorewall configuration uses policy routing (providers). - You were pinging from a host connected to eth1.4. - From the routing rules, traffic entering on eth1.4 is routed via table WRLS. 1000: from all iif eth1.4 lookup WRLS - Table WRLS has no route to 10.1.19.248 except back out of eth1.4 209.53.153.254 dev eth0 scope link src 209.53.153.50 209.53.153.0/24 dev eth0 proto kernel scope link src 209.53.153.50 10.1.20.0/24 dev eth1.5 proto kernel scope link src 10.1.20.1 10.1.19.0/24 dev eth1.4 proto kernel scope link src 10.1.19.1 169.254.0.0/16 dev eth1.5 scope link default via 209.53.153.254 dev eth0 src 209.53.153.50 - Therefore, the firewall apparently ignores the packet even though there is a perm ARP table entry for 10.1.19.248. ? (10.1.19.248) at * PERM PUP on eth1.4 When you have VPN connections that come and go, it is recommended that you set USE_DEFAULT_RT=Yes which causes all packets to be first routed via the main table and only if they don''t match an entry in the main table do they get sent to a provider table. In this configuration, there is no default route in the main table. This allows dynamic changes in the main table to be visible to all packets. The alternative is to include ppp0 in the COPY column for the WRLS provider and restart Shorewall each time that a pptp link comes 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 \________________________________________________ ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev
On 11/12/2010 11:29 AM, Tom Eastep wrote:> > One key piece of information that was omitted is that your Shorewall > configuration uses policy routing (providers). > > - Therefore, the firewall apparently ignores the packet even though > there is a perm ARP table entry for 10.1.19.248. > > ? (10.1.19.248) at * PERM PUP on eth1.4 > > When you have VPN connections that come and go, it is recommended that > you set USE_DEFAULT_RT=Yes which causes all packets to be first routed > via the main table and only if they don''t match an entry in the main > table do they get sent to a provider table. In this configuration, there > is no default route in the main table. This allows dynamic changes in > the main table to be visible to all packets. >That was the fix, thank you. I had turned off USE_DEFAULT_RT so that systems on the PROC (industrial) side of the network would have no knowledge of the routes on the CORP (business) side. Is there any harm or advantage in using route_rules to accomplish the same thing? ie, instead of having the corporate routes in route-eth1.2 so that they end up in the main table as in... 198.162.160.0/19 via 10.1.16.254 dev eth1.2 199.60.192.0/20 via 10.1.16.254 dev eth1.2 192.40.217.0/24 via 10.1.16.254 dev eth1.2 192.168.0.0/16 via 10.1.16.254 dev eth1.2 172.16.0.0/12 via 10.1.16.254 dev eth1.2 10.0.0.0/8 via 10.1.16.254 dev eth1.2 I add them to the route_rules as in... #SOURCE DEST PROVIDER PRIORITY eth1.2 - CORP 1000 eth1.3 - CORP 1000 eth1.4 - WRLS 1000 eth1.5 - WRLS 1000 - 198.162.160.0/19 CORP 1001 - 199.60.192.0/20 CORP 1001 - 192.40.217.0/24 CORP 1001 - 192.168.0.0/16 CORP 1001 - 172.16.0.0/12 CORP 1001 - 10.0.0.0/8 CORP 1001 With the resulting routing senario. Routing Rules 0: from all lookup 255 999: from all lookup main 1000: from all iif eth1.2 lookup CORP 1000: from all iif eth1.3 lookup CORP 1000: from all iif eth1.4 lookup WRLS 1000: from all iif eth1.5 lookup WRLS 1001: from all to 198.162.160.0/19 lookup CORP 1001: from all to 199.60.192.0/20 lookup CORP 1001: from all to 192.40.217.0/24 lookup CORP 1001: from all to 192.168.0.0/16 lookup CORP 1001: from all to 172.16.0.0/12 lookup CORP 1001: from all to 10.0.0.0/8 lookup CORP 10000: from all fwmark 0x1 lookup CORP 10001: from all fwmark 0x2 lookup WRLS 20000: from 10.1.16.22 lookup CORP 20256: from 204.244.116.180 lookup WRLS 32767: from all lookup default Table CORP: 10.1.16.254 dev eth1.2 scope link src 10.1.16.22 default via 10.1.16.254 dev eth1.2 src 10.1.16.22 Table default: default nexthop via 10.1.16.254 dev eth1.2 weight 1 nexthop via 204.244.116.190 dev eth0 weight 1 Table main: 204.244.116.128/26 dev eth0 proto kernel scope link src 204.244.116.180 10.1.20.0/24 dev eth1.5 proto kernel scope link src 10.1.20.1 10.1.16.0/24 dev eth1.2 proto kernel scope link src 10.1.16.22 10.1.17.0/24 dev eth1.3 proto kernel scope link src 10.1.17.1 10.1.19.0/24 dev eth1.4 proto kernel scope link src 10.1.19.1 Table WRLS: 204.244.116.190 dev eth0 scope link src 204.244.116.180 default via 204.244.116.190 dev eth0 src 204.244.116.180> The alternative is to include ppp0 in the COPY column for the WRLS > provider and restart Shorewall each time that a pptp link comes up. >I don''t think I want the firewall changing on a busy router. One other question. How do I force the firewall itself to use eth0 and its default route for outgoing connections? As it is I have a 50/50 chance of hitting the corporate ISA server for outgoing connections for yum updates and ssh sessions. It is just those two protocols that I am concerned about. Would it fit in tcrules? Thanks again Tom for your help. ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev
On 11/15/10 9:13 AM, Alan Madill wrote:> > > On 11/12/2010 11:29 AM, Tom Eastep wrote: >> >> One key piece of information that was omitted is that your Shorewall >> configuration uses policy routing (providers). >> >> - Therefore, the firewall apparently ignores the packet even though >> there is a perm ARP table entry for 10.1.19.248. >> >> ? (10.1.19.248) at * PERM PUP on eth1.4 >> >> When you have VPN connections that come and go, it is recommended that >> you set USE_DEFAULT_RT=Yes which causes all packets to be first routed >> via the main table and only if they don''t match an entry in the main >> table do they get sent to a provider table. In this configuration, there >> is no default route in the main table. This allows dynamic changes in >> the main table to be visible to all packets. >> > > That was the fix, thank you. I had turned off USE_DEFAULT_RT so that systems on > the PROC (industrial) side of the network would have no knowledge of the routes > on the CORP (business) side.How would they get this knowledge? If your firewall rules prohibit such traffic, why does the existence of these routes matter?> > One other question. How do I force the firewall itself to use eth0 and its > default route for outgoing connections? As it is I have a 50/50 chance of > hitting the corporate ISA server for outgoing connections for yum updates and > ssh sessions. It is just those two protocols that I am concerned about. Would > it fit in tcrules?Yes -- with $FW as the source. Note that you may have to resort to the routing rule that is given in "Applications running on the Firewall -making them use a particular provider" section of the Shorewall Multi-ISP doc. -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 \________________________________________________ ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev
On 11/15/2010 11:16 AM, Tom Eastep wrote:> >> That was the fix, thank you. I had turned off USE_DEFAULT_RT so that systems on >> the PROC (industrial) side of the network would have no knowledge of the routes >> on the CORP (business) side. > How would they get this knowledge? If your firewall rules prohibit such > traffic, why does the existence of these routes matter?They would get this knowledge by hitting the "main" table before the CORP or PROC tables if the routing was in "main". As for why... Efficiency? Because some of these IPs are accessible when routed via the Internet and they are not allowed via the corporate side? That''s why I asked... Is there any harm or advantage in using route_rules to accomplish the same thing? ie, instead of having the corporate routes in route-eth1.2 so that they end up in the main table? Is there an additional processing cost for the router? Perhaps I am not understanding the flow. Does it work like... 0: from all lookup 255 999: from all lookup main 1000: from all iif eth1.2 lookup CORP 1000: from all iif eth1.3 lookup CORP 1000: from all iif eth1.4 lookup WRLS ^ The packet arrived via eth1.4 destined for 198.162.160.xxx and Table WRLS: says 204.244.116.190 dev eth0 scope link src 204.244.116.180 default via 204.244.116.190 dev eth0 src 204.244.116.180 ^ so send it out via the default 1000: from all iif eth1.5 lookup WRLS 1001: from all to 198.162.160.0/19 lookup CORP ^ Never getting here Which would mean adding any additional routing beyond the default is redundant. (If the defaults cover it) Am I getting it? Thanks for your patience. ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev
On 11/15/10 8:11 PM, Alan Madill wrote:> > > On 11/15/2010 11:16 AM, Tom Eastep wrote: >> >>> That was the fix, thank you. I had turned off USE_DEFAULT_RT so that systems on >>> the PROC (industrial) side of the network would have no knowledge of the routes >>> on the CORP (business) side. >> How would they get this knowledge? If your firewall rules prohibit such >> traffic, why does the existence of these routes matter? > > They would get this knowledge by hitting the "main" table before the CORP or > PROC tables if the routing was in "main".So what? Again, if your firewall rules prohibit such traffic then "They" gain no additional knowledge.> > As for why... Efficiency? Because some of these IPs are accessible when routed > via the Internet and they are not allowed via the corporate side? > > That''s why I asked...> > Is there any harm or advantage in using route_rules to accomplish the same > thing? ie, instead of having the corporate routes in route-eth1.2 so that they > end up in the main table? > > Is there an additional processing cost for the router? > > Perhaps I am not understanding the flow. Does it work like... > > 0: from all lookup 255 > 999: from all lookup main > 1000: from all iif eth1.2 lookup CORP > 1000: from all iif eth1.3 lookup CORP > > 1000: from all iif eth1.4 lookup WRLS > > ^ The packet arrived via eth1.4 destined for 198.162.160.xxx and Table WRLS: says > > 204.244.116.190 dev eth0 scope link src 204.244.116.180 > default via 204.244.116.190 dev eth0 src 204.244.116.180 > > ^ so send it out via the defaultYes.> > 1000: from all iif eth1.5 lookup WRLS > 1001: from all to 198.162.160.0/19 lookup CORP > > ^ Never getting hereThat''s correct -- routing rules are "first match wins".> > Which would mean adding any additional routing beyond the default is redundant. > (If the defaults cover it) Am I getting it?Additional routing *rules*, yes. Shorewall''s ''provider'' mechanism isn''t designed to allow arbitrary routes to be defined in the provider tables. The only way to add routes to one of these tables is to add them to the main table and have them copied from there. -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 \________________________________________________ ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev
On 11/16/10 6:54 AM, Tom Eastep wrote:> > Shorewall''s ''provider'' mechanism isn''t designed to allow arbitrary > routes to be defined in the provider tables.Actually, it isn''t a design issue; the design permits it but there is currently no way to define such routes. -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 \________________________________________________ ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev