Hello Tom,
I have successfully configured proxy arp subnettinng on my network with
three hosts in a Dmz.
And it works great. (using proxyarp in interfaces) I also tryed this on
network below same trouble.
However for this network below I have tryed to configure one host in a
Dmz (using /etc/shorewall/proxyarp) which works and comes up after I set it
up
and clear Isp''s arp cache. But the Dmz server is slow when trying to
hit the
web server and times out on web server connections.
Web pages may or may not come up when I called people outside my netwok to
test it.
The only difference is the network below and my network is this netork
is running ipsec and ipsec complained of duplicate
IP when I entered 64.42.53.203 on eth2 so as you can see below I configured
eth2 192.168.10.0/24.
I tried two different nights to set this up one night I used crossover
cable between eth2 and Dmz and had same
problem (slow or no connections from outside networks on the net) I could
get successfull high speed connections to the Dmz server from
the internal lan to the Dmz server.
The second night I thought since the Dmz server has a gigbit nic and
shorewall eth2 did not that this may be the trouble. So I put a Cisco
10/100 swich between shorewall eth2 and Dmz servers single nic 10/1000. And
I came up with same trouble.
Since the server has to be up 24/7 I have it back out on the firing line
(net).
Can the list provide me with any suggestions how to trouble shoot this. If
not I was thinking (which is a lot of trouble to bring another server in
to test this Dmz)
Thanks,
Mike
PS. Does anyone know how to tell ipsec not to add the 169.254 network below
:(
[root@ns1 root]# /sbin/shorewall status > /tmp/status.txt
[root@ns1 root]# ip route show
64.42.53.200/29 dev eth0 scope link
64.42.53.200/29 dev eth0 proto kernel scope link src 64.42.53.202
64.42.53.200/29 dev ipsec0 proto kernel scope link src 64.42.53.202
10.192.139.0/24 via 64.42.53.201 dev ipsec0
10.201.144.0/24 via 10.19.227.193 dev eth1
10.19.227.0/24 dev eth1 scope link
192.168.10.0/24 dev eth2 scope link
172.30.0.0/16 via 10.19.227.190 dev eth1
169.254.0.0/16 dev eth2 scope link
127.0.0.0/8 dev lo scope link
default via 64.42.53.201 dev eth0
[root@ns1 root]# shorewall version
2.0.2c
[root@ns1 root]# ip route show
64.42.53.200/29 dev eth0 scope link
64.42.53.200/29 dev eth0 proto kernel scope link src 64.42.53.202
64.42.53.200/29 dev ipsec0 proto kernel scope link src 64.42.53.202
10.192.139.0/24 via 64.42.53.201 dev ipsec0
10.201.144.0/24 via 10.19.227.193 dev eth1
10.19.227.0/24 dev eth1 scope link
192.168.10.0/24 dev eth2 scope link
172.30.0.0/16 via 10.19.227.190 dev eth1
169.254.0.0/16 dev eth2 scope link
127.0.0.0/8 dev lo scope link
default via 64.42.53.201 dev eth0
[root@ns1 root]# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
5: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:e2:18:93:1b brd ff:ff:ff:ff:ff:ff
inet 10.19.227.20/24 brd 10.19.227.255 scope global eth1
6: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:e2:1c:f5:db brd ff:ff:ff:ff:ff:ff
inet 64.42.53.202/29 brd 64.42.53.207 scope global eth0
7: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.100.255 scope global eth2
12: ipsec0: <NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 10
link/ether 00:04:e2:1c:f5:db brd ff:ff:ff:ff:ff:ff
inet 64.42.53.202/29 brd 64.42.53.207 scope global ipsec0
13: ipsec1: <NOARP> mtu 0 qdisc noop qlen 10
link/void
14: ipsec2: <NOARP> mtu 0 qdisc noop qlen 10
link/void
15: ipsec3: <NOARP> mtu 0 qdisc noop qlen 10
link/void
[root@ns1 root]#
On Thu, 2004-12-30 at 09:14 -0800, Mike Lander wrote:> Since the server has to be up 24/7 I have it back out on the firing line > (net). > Can the list provide me with any suggestions how to trouble shoot this. If > not I was thinking (which is a lot of trouble to bring another server in > to test this Dmz)I would capture a packet trace on the firewall''s external interface. Be sure to capture all traffic associated with the server.> > Thanks, > Mike > > PS. Does anyone know how to tell ipsec not to add the 169.254 network below > :(It''s probably not IPSEC that is creating the route -- check the archives; this question gets asked periodically.> [root@ns1 root]# ip route show > 64.42.53.200/29 dev eth0 scope link > 64.42.53.200/29 dev eth0 proto kernel scope link src 64.42.53.202 > 64.42.53.200/29 dev ipsec0 proto kernel scope link src 64.42.53.202 > 10.192.139.0/24 via 64.42.53.201 dev ipsec0 > 10.201.144.0/24 via 10.19.227.193 dev eth1 > 10.19.227.0/24 dev eth1 scope link > 192.168.10.0/24 dev eth2 scope link > 172.30.0.0/16 via 10.19.227.190 dev eth1 > 169.254.0.0/16 dev eth2 scope link > 127.0.0.0/8 dev lo scope link > default via 64.42.53.201 dev eth0Where is the route to the server connected to eth2? Or did you really gather all of this information while the server WASN''T behind the firewall? -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
> Where is the route to the server connected to eth2? Or did you really > gather all of this information while the server WASN''T behind the > firewall? > > -TomI gathered when the dmz WASN''T behind the firewall? With hopes that someone would find a typo I made or wrong config. I know thats my job but I have went over this until blue :<) face! Thanks Mike
On Thu, 2004-12-30 at 11:15 -0800, Mike Lander wrote:> > Where is the route to the server connected to eth2? Or did you really > > gather all of this information while the server WASN''T behind the > > firewall? > > > > -Tom > I gathered when the dmz WASN''T behind the firewall? With hopes > that someone would find a typo I made or wrong config. I know thats > my job but I have went over this until blue :<) face!Shorewall configuration errors usually result in connections being denied. Unless you are using rate-limiting (which I didn''t see in your config), it''s hard to envision how Shorewall can make traffic go slowly after connections have been established (which sounds like what is happening in your case). -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
>> I gathered when the dmz WASN''T behind the firewall? With hopes >> that someone would find a typo I made or wrong config. I know thats >> my job but I have went over this until blue :<) face! > > Shorewall configuration errors usually result in connections being > denied. Unless you are using rate-limiting (which I didn''t see in your > config), it''s hard to envision how Shorewall can make traffic go slowly > after connections have been established (which sounds like what is > happening in your case). > > -TomYes the first night I tryed this it was up three days until someone noticed web site timing out etc; the odd thing is that the Dmz (windoz 2000 server) is running 300 e-mail clients pop3 and smtp and I recieved no e-mail compaints which I assumed the trouble was just on port 80 because oddly you could hit port 443 and the connections where fast. Parts of the web page gif''s for example in the javascript nav menu would be missing as you watched browser time outs. Yet if you hit the same page on 443 no trouble. So I need some week end time to trouble shoot, this is hard to do when so many people depend on a server that you can''t test for very long. Tom''s advice I would capture a packet trace on the firewall''s external interface. Be sure to capture all traffic associated with the server. Are you talking about tcpdump -nei eth0 (net)???? Thanks for the advice. -------------Mike
I think I found the trouble, I was looking at output of shorewall status
I noticed dmz old address 192.168.100.255
Chain smurfs (0 references)
pkts bytes target prot opt in out source
destination
0 0 LOG all -- * * 64.42.53.207
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 64.42.53.207
0.0.0.0/0
0 0 LOG all -- * * 10.19.227.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 10.19.227.255
0.0.0.0/0
0 0 LOG all -- * * 192.168.100.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 192.168.100.255
0.0.0.0/0
0 0 LOG all -- * * 255.255.255.255
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 255.255.255.255
0.0.0.0/0
0 0 LOG all -- * * 224.0.0.0/4
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:''
0 0 DROP all -- * * 224.0.0.0/4 0.0.0.0/
note broadcast below
I found old dmz broadcast entry
eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:e2:18:ad:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.100.255 scope global eth2
How the world did I do this???
Thanks Tom
Mike