Hi all,
After having successfully recompiled my ubuntu kernel for CONNMARK support to
get multi-isp support working, I am now working on adding a couple of hosts in
my DMZ using Proxyarp and having what appears to be a weird issue. My first test
is to hit a web server on port 80.
On my router/firewall, eth0 is the internal network, and eth1-x are my
different ISPs. On eth0 I have VLANs setup for various internal networks. My dmz
is on one of these vlans. I have a /29 on eth1 so I have 5 public IP addresses.
Let''s call it 198.162.214.240/29.
eth1 is 198.162.214.242, subnet mask 255.255.255.248, gateway 198.162.214.241
I am adding a host in my dmz with an address of 198.162.214.243, subnet mask
255.255.255.248, gateway 198.162.214.241.
The host is on VLAN 120. On the router, on interface eth0.120 there is an
address of 192.168.120.254, subnet mask of 255.255.255.0 (as I read, that part
really shouldn''t matter)
in /etc/shorewall/proxyarp I have one line
Address Interface External Haveroute
198.162.214.243 eth0.120 eth1 No
in /etc/shorewall/policy I have all traffic originating in the dmz to any other
zone to be REJECTed, and any traffic coming from the internet to the dmz zone
marked to DROP.
in /etc/shorewall/rules
ACCEPT $FW dmz icmp
Ping/ACCEPT net dmz:198.162.214.243 icmp
ACCEPT net dmz:198.162.214.243 tcp 80
I then restarted shorewall, and I did "ip route ls" I see as the
first line:
198.162.214.243 dev eth0.120 scope link
I find that I can successfully ping 198.162.214.243 from the firewall.
However if I come in from the internet to the web site, I see nothing, and if I
look in the log I see this:
Shorewall:FORWARD:REJECT: IN=eth1 OUT=eth1 MAC=00 SRC=x.x.x.x
DST=198.162.214.243 LEN=60 TOS=00 PREC=0x00 TTL=59 ID=44361 CE DF PROTO=TCP
SPT=14259 DPT=80 SEQ=2177425409
If I ping I see a similar rejection.
What surprises me here, is that IN and OUT are both eth1 and thats the obvious
reason it is being REJECTed.
Why do I get eth1 on both IN and OUT? shouldn''t OUT be eth0.120 ?? Am
I missing an entry that I should have in another file?
Regards,
John
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news,
photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
J M wrote:> > However if I come in from the internet to the web site, I see nothing, > and if I look in the log I see this: > > Shorewall:FORWARD:REJECT: IN=eth1 OUT=eth1 MAC=00 SRC=x.x.x.x > DST=198.162.214.243 LEN=60 TOS=00 PREC=0x00 TTL=59 ID=44361 CE DF > PROTO=TCP SPT=14259 DPT=80 SEQ=2177425409 > > If I ping I see a similar rejection. > > What surprises me here, is that IN and OUT are both eth1 and thats the > obvious reason it is being REJECTed. > > > Why do I get eth1 on both IN and OUT?Your routing is screwed up. If you need further help, please submit a shorewall dump collected as described at http://www.shorewall.net/support.htm#Guidelines -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> J M wrote: > >> However if I come in from the internet to the web site, I see nothing, >> and if I look in the log I see this: >> >> Shorewall:FORWARD:REJECT: IN=eth1 OUT=eth1 MAC=00 SRC=x.x.x.x >> DST=198.162.214.243 LEN=60 TOS=00 PREC=0x00 TTL=59 ID=44361 CE DF >> PROTO=TCP SPT=14259 DPT=80 SEQ=2177425409 >> >> If I ping I see a similar rejection. >> >> What surprises me here, is that IN and OUT are both eth1 and thats the >> obvious reason it is being REJECTed. >> >> >> Why do I get eth1 on both IN and OUT? > > Your routing is screwed up.In particular, Proxy ARP is very hard to get right with multi-ISP (remember all of the warnings at the top of the multi-ISP article indicating that the reader really needs to understand this stuff in order to use it?). You have two options: a) Rather than specifying ''No'' in the HAVEROUTE column of /etc/shorewall/proxyarp, you should add the host routes to the DMZ servers as part of your distribution''s configuration of eth0.120. That way, it will be copied to the routing table corresponding to eth1 as a result of ''eth0.120'' (or eth0.*) appearing in the COPY column of the providers file. That''s the approach that I take when I''m testing Multi-ISP. or) b) Add a route rule that directs all traffic to the DMZ servers to use the main routing table. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> J M wrote: > >> However if I come in from the internet to the web site, I see nothing, >> and if I look in the log I see this: >> >> Shorewall:FORWARD:REJECT: IN=eth1 OUT=eth1 MAC=00 SRC=x.x.x.x >> DST=198.162.214.243 LEN=60 TOS=00 PREC=0x00 TTL=59 ID=44361 CE DF >> PROTO=TCP SPT=14259 DPT=80 SEQ=2177425409 >> >> If I ping I see a similar rejection. >> >> What surprises me here, is that IN and OUT are both eth1 and thats the >> obvious reason it is being REJECTed. >> >> >> Why do I get eth1 on both IN and OUT? > > Your routing is screwed up.In particular, Proxy ARP is very hard to get right with multi-ISP (remember all of the warnings at the top of the multi-ISP article indicating that the reader really needs to understand this stuff in order to use it?). You have two options: a) Rather than specifying ''No'' in the HAVEROUTE column of /etc/shorewall/proxyarp, you should add the host routes to the DMZ servers as part of your distribution''s configuration of eth0.120. That way, it will be copied to the routing table corresponding to eth1 as a result of ''eth0.120'' (or eth0.*) appearing in the COPY column of the providers file. That''s the approach that I take when I''m testing Multi-ISP. or) b) Add a route rule that directs all traffic to the DMZ servers to use the main routing table. One thing which I missed was adding the dmz interface to my /etc/shorewall/providers file. I believe this was the only error. I restarted shorewall, and everything appears to work as advertised. The only thing I notice now, is that on a reboot of the firewall, the rules dont seem to apply, I get ton of REJECT packets for example (in the shorewall log), when I try to ping the host from the firewall. However if I simply do a "shorewall restart" then everything works again. I''m working on that one.. Regards, John ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
J M wrote:> > The only thing I notice now, is that on a reboot of the firewall, the > rules dont seem to apply, I get ton of REJECT packets for example (in > the shorewall log), when I try to ping the host from the firewall. > However if I simply do a "shorewall restart" then everything works > again. I''m working on that one..The order of operations in Shorewall is that providers are established before Proxy ARP routes are added. So you will always have to restart at least once after boot to get the proxy arp routes copied into the provider routing tables. That''s why I recommended adding those routes as part of bringing up the DMZ interface rather than having Shorewall do it. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote:> J M wrote: > >> The only thing I notice now, is that on a reboot of the firewall, the >> rules dont seem to apply, I get ton of REJECT packets for example (in >> the shorewall log), when I try to ping the host from the firewall. >> However if I simply do a "shorewall restart" then everything works >> again. I''m working on that one.. > > The order of operations in Shorewall is that providers are established > before Proxy ARP routes are added. So you will always have to restart at > least once after boot to get the proxy arp routes copied into the provider > routing tables. > > That''s why I recommended adding those routes as part of bringing up the DMZ > interface rather than having Shorewall do it.Please disregard the above drivel -- Proxy ARP is established before providers (at least in Shorewall 4.0). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/