I am trying to setup what I think is pretty straight forward DNAT rules and they always fail. Below is the rule I have and the log entry I get. I read the FAQ and have checked the gateway address and all that stuff, but it still gets rejected. I am a bit confused by it showing in the log that IN and OUT are both eth1. I have checked 50 times and the interfaces are configured properly. (So far as I can tell.) Any ideas? Rule: DNAT all loc:192.168.15.5 tcp http - 66.193.183.5 Log message: Aug 4 09:23:21 firewall kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=66.193.183.25 DST=192.168.15.5 LEN=48 TOS=0x08 PREC=0x00 TTL=127 ID=12783 DF PROTO=TCP SPT=4862 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0 Thanks! ________________________________________ Chip Burke ________________________________________
Chip Burke wrote:> I am trying to setup what I think is pretty straight forward DNAT rules and > they always fail. Below is the rule I have and the log entry I get. I read > the FAQ and have checked the gateway address and all that stuff, but it > still gets rejected. I am a bit confused by it showing in the log that IN > and OUT are both eth1. I have checked 50 times and the interfaces are > configured properly. (So far as I can tell.) Any ideas? >Do you have both interfaces connected to the same hub/switch? -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
Yes, but they are on different VLANS. One VLAN serves our public facing hosts, the other VLAN servers our internal stuff. So technically yes, but in practice, they are not in the same broadcast domain if that is where you are going. ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, August 04, 2005 10:35 AM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Chip Burke wrote:> I am trying to setup what I think is pretty straight forward DNAT rulesand> they always fail. Below is the rule I have and the log entry I get. I read > the FAQ and have checked the gateway address and all that stuff, but it > still gets rejected. I am a bit confused by it showing in the log that IN > and OUT are both eth1. I have checked 50 times and the interfaces are > configured properly. (So far as I can tell.) Any ideas? >Do you have both interfaces connected to the same hub/switch? -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:> Yes, but they are on different VLANS. One VLAN serves our public facing > hosts, the other VLAN servers our internal stuff. So technically yes, but in > practice, they are not in the same broadcast domain if that is where you are > going. >You might want to check your VLAN configuration. You''ve given us no details but I''m guessing that eth1 is your internal interface. The reason internet traffic would be entering your system on that interface is because, by default, Linux responds to ARP "who-has" requests on any interface that receives it. So if the upstream router sent an ARP "who-has" for your external IP, it could be responded to with the MAC of the internal interface if that interface happened to receive the request. Now if eth1 is your external interface, the message is indicating that 192.168.15.5 is routed out of that interface; possibly, 192.168.15.5 is not the correct IP address for the server? -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
Eth1 is indeed the internal interface, but I have just tried this with separate switches and get the same results. I am not hip to ARP caching as I have never had to deal with this on any firewall before. (Until now I have always used PIX or Watchguard type appliances.) Is there some ARP cache config I need to do? As it stands now, my ARP cache config file is empty except for the comments that come in it. ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, August 04, 2005 10:53 AM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Chip Burke wrote:> Yes, but they are on different VLANS. One VLAN serves our public facing > hosts, the other VLAN servers our internal stuff. So technically yes, butin> practice, they are not in the same broadcast domain if that is where youare> going. >You might want to check your VLAN configuration. You''ve given us no details but I''m guessing that eth1 is your internal interface. The reason internet traffic would be entering your system on that interface is because, by default, Linux responds to ARP "who-has" requests on any interface that receives it. So if the upstream router sent an ARP "who-has" for your external IP, it could be responded to with the MAC of the internal interface if that interface happened to receive the request. Now if eth1 is your external interface, the message is indicating that 192.168.15.5 is routed out of that interface; possibly, 192.168.15.5 is not the correct IP address for the server? -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:> Eth1 is indeed the internal interface, but I have just tried this with > separate switches and get the same results. I am not hip to ARP caching as I > have never had to deal with this on any firewall before. (Until now I have > always used PIX or Watchguard type appliances.) Is there some ARP cache > config I need to do? As it stands now, my ARP cache config file is empty > except for the comments that come in it.There is nothing that I know of that can cause external traffic to enter your internal interface except physical cabling/configuration problems (or confusion over which interface is which). -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
Tom Eastep wrote:> Chip Burke wrote: >>Eth1 is indeed the internal interface, but I have just tried this with >>separate switches and get the same results. I am not hip to ARP caching as I >>have never had to deal with this on any firewall before. (Until now I have >>always used PIX or Watchguard type appliances.) Is there some ARP cache >>config I need to do? As it stands now, my ARP cache config file is empty >>except for the comments that come in it. > > There is nothing that I know of that can cause external traffic to enter > your internal interface except physical cabling/configuration problems (or > confusion over which interface is which). >If you can''t get it working, please submit a proper problem report (see http://www.shorewall.net/support.htm) and we''ll take a look. Again, though, this doesn''t sound like a problem with the configuration on your 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
On Thu, 4 Aug 2005, Chip Burke wrote:> I am trying to setup what I think is pretty straight forward DNAT rules and > they always fail. Below is the rule I have and the log entry I get. I read > the FAQ and have checked the gateway address and all that stuff, but it > still gets rejected. I am a bit confused by it showing in the log that IN > and OUT are both eth1. I have checked 50 times and the interfaces are > configured properly. (So far as I can tell.) Any ideas? > > > > Rule: > > DNAT all loc:192.168.15.5 tcp http - > 66.193.183.5I''d suggest changing ''all'' in the above rule to whatever you call your external interface in zones. For some reason your external traffic appears to be entering via eth1 then is leaving via eth1 to your internal network. This should not be happening and indicates a serious misconfiguration. Use tethereal or tcpdump to verify this is happenng. You''re not trying to use the same physical port for both external and internal traffic are you? Even if they have different subinterfaces this is a very bad idea on any firewall setup. Try clearing the arp cache on your switch. Then from the switch, ping both the external address of your firewall and the internal address. Check the arp cache. Are the MAC addreses the same or different?> > > Log message: > > > > Aug 4 09:23:21 firewall kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 > SRC=66.193.183.25 DST=192.168.15.5 LEN=48 TOS=0x08 PREC=0x00 TTL=127 > ID=12783 DF PROTO=TCP SPT=4862 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0 > > > > Thanks! > > > > ________________________________________ > Chip Burke > > ________________________________________ > > > >------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Stephen Carville wrote:>> Rule: >> >> DNAT all loc:192.168.15.5 tcp http - >> 66.193.183.5 > > I''d suggest changing ''all'' in the above rule to whatever you call your > external interface in zones. >Good catch, Stephen -- I missed that. -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 am pretty much bewildered at this point. Everything else works....
masquerade, ports open to the firewall itself. But DNAT doesn''t work at
all.
Now it is not even logging the same things as before. It doesn''t seem
to log
any DNAT activity. I am 100% certain I have the interfaces connected
correctly. Right now I have torn the firewall out and put it in test
environment with a different hub on either interface. Here is the IPTables
output. I know it is a lot, but I am hoping someone can find something
goofed up in one of the chains that I have missed.
TERM environment variable not set.
Shorewall-1.4.8 Status at firewall - Thu Aug 4 11:39:18 EDT 2005
Counters reset Thu Aug 4 11:34:00 EDT 2005
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 DROP !icmp -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID
12 576 eth0_fwd all -- eth0 * 0.0.0.0/0
0.0.0.0/0
6 378 eth1_fwd all -- eth1 * 0.0.0.0/0
0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 limit: avg 20/min burst 5 LOG flags 0 level 6 prefix
`Shorewall:FORWARD:REJECT:''
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
4 396 ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID
781 38395 eth0_in all -- eth0 * 0.0.0.0/0
0.0.0.0/0
164 13886 eth1_in all -- eth1 * 0.0.0.0/0
0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 limit: avg 20/min burst 5 LOG flags 0 level 6 prefix
`Shorewall:INPUT:REJECT:''
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
10 942 ACCEPT all -- * lo 0.0.0.0/0
0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID
21 1234 fw2all all -- * eth0 0.0.0.0/0
0.0.0.0/0
167 104K fw2loc all -- * eth1 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain all2all (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
0 0 common all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 limit: avg 20/min burst 5 LOG flags 0 level 6 prefix
`Shorewall:all2all:REJECT:''
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain common (4 references)
pkts bytes target prot opt in out source
destination
0 0 icmpdef icmp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:135
20 1867 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:445
3 144 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:139
3 144 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:445
3 144 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:135
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:1900
0 0 DROP all -- * * 0.0.0.0/0
255.255.255.255
0 0 DROP all -- * * 0.0.0.0/0
224.0.0.0/4
3 144 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:113
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp spt:53 state NEW
0 0 DROP all -- * * 0.0.0.0/0
66.193.183.63
0 0 DROP all -- * * 0.0.0.0/0
192.168.15.255
Chain dynamic (4 references)
pkts bytes target prot opt in out source
destination
Chain eth0_fwd (1 references)
pkts bytes target prot opt in out source
destination
12 576 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state NEW
12 576 net2loc all -- * eth1 0.0.0.0/0
0.0.0.0/0
Chain eth0_in (1 references)
pkts bytes target prot opt in out source
destination
781 38395 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state NEW
781 38395 net2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain eth1_fwd (1 references)
pkts bytes target prot opt in out source
destination
6 378 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state NEW
6 378 loc2net all -- * eth0 0.0.0.0/0
0.0.0.0/0
Chain eth1_in (1 references)
pkts bytes target prot opt in out source
destination
16 891 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state NEW
164 13886 loc2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain fw2all (2 references)
pkts bytes target prot opt in out source
destination
17 950 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
4 284 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain fw2loc (1 references)
pkts bytes target prot opt in out source
destination
167 104K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.5 state NEW tcp dpt:1723 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:80 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:443 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:21 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:25 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:110 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:8443 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.222 state NEW tcp dpt:21 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.9 state NEW tcp dpt:80 ctorigdst 66.193.183.10
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.9 state NEW tcp dpt:443 ctorigdst 66.193.183.10
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.8 state NEW tcp dpt:80 ctorigdst 66.193.183.9
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.31 state NEW tcp dpt:6000 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:8080 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:8021 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.4 state NEW tcp dpt:80 ctorigdst 66.193.183.11
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.4 state NEW tcp dpt:443 ctorigdst 66.193.183.11
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:22 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.223 state NEW tcp dpt:80 ctorigdst 66.193.183.12
0 0 fw2all all -- * * 0.0.0.0/0
0.0.0.0/0
Chain icmpdef (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 8
Chain loc2fw (1 references)
pkts bytes target prot opt in out source
destination
148 12995 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
16 891 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain loc2loc (0 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.5 state NEW tcp dpt:1723 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:80 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:443 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:21 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:25 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:110 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:8443 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.222 state NEW tcp dpt:21 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.9 state NEW tcp dpt:80 ctorigdst 66.193.183.10
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.9 state NEW tcp dpt:443 ctorigdst 66.193.183.10
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.8 state NEW tcp dpt:80 ctorigdst 66.193.183.9
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.31 state NEW tcp dpt:6000 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:8080 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:8021 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.4 state NEW tcp dpt:80 ctorigdst 66.193.183.11
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.4 state NEW tcp dpt:443 ctorigdst 66.193.183.11
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:22 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.223 state NEW tcp dpt:80 ctorigdst 66.193.183.12
0 0 all2all all -- * * 0.0.0.0/0
0.0.0.0/0
Chain loc2net (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
6 378 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2all (2 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
781 38395 common all -- * * 0.0.0.0/0
0.0.0.0/0
5 240 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 limit: avg 20/min burst 5 LOG flags 0 level 6 prefix
`Shorewall:net2all:DROP:''
749 35952 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2fw (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
0 0 DROP icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 8
781 38395 net2all all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2loc (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 newnotsyn tcp -- * * 0.0.0.0/0
0.0.0.0/0 state NEW tcp flags:!0x16/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.5 state NEW tcp dpt:1723 ctorigdst 66.193.183.5
10 480 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.11 state NEW tcp dpt:80 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:80 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:443 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:21 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:25 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:110 ctorigdst 66.193.183.7
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.7 state NEW tcp dpt:8443 ctorigdst 66.193.183.7
1 48 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.222 state NEW tcp dpt:21 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.9 state NEW tcp dpt:80 ctorigdst 66.193.183.10
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.9 state NEW tcp dpt:443 ctorigdst 66.193.183.10
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.8 state NEW tcp dpt:80 ctorigdst 66.193.183.9
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.31 state NEW tcp dpt:6000 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:8080 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:8021 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.4 state NEW tcp dpt:80 ctorigdst 66.193.183.11
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.4 state NEW tcp dpt:443 ctorigdst 66.193.183.11
1 48 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.32 state NEW tcp dpt:22 ctorigdst 66.193.183.5
0 0 ACCEPT tcp -- * * 0.0.0.0/0
192.168.15.223 state NEW tcp dpt:80 ctorigdst 66.193.183.12
0 0 net2all all -- * * 0.0.0.0/0
0.0.0.0/0
Chain newnotsyn (9 references)
pkts bytes target prot opt in out source
destination
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 limit: avg 20/min burst 5 LOG flags 0 level 6 prefix
`Shorewall:newnotsyn:DROP:''
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain reject (10 references)
pkts bytes target prot opt in out source
destination
12 576 REJECT tcp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with tcp-reset
20 1867 REJECT udp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT icmp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-unreachable
0 0 REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-prohibited
Chain shorewall (0 references)
pkts bytes target prot opt in out source
destination
Aug 3 22:17:31 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.15.223
DST=192.168.15.7 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=4886 DF PROTO=TCP
SPT=4294 DPT=110 WINDOW=65535 RES=0x00 SYN URGP=0
Aug 3 22:18:59 newnotsyn:DROP:IN=eth0 OUT= SRC=64.152.17.157
DST=66.193.183.5 LEN=1500 TOS=0x08 PREC=0x00 TTL=48 ID=43257 PROTO=TCP
SPT=80 DPT=1324 WINDOW=16080 RES=0x00 ACK URGP=0
Aug 3 22:20:59 newnotsyn:DROP:IN=eth0 OUT= SRC=64.152.17.157
DST=66.193.183.5 LEN=1500 TOS=0x08 PREC=0x00 TTL=48 ID=43258 PROTO=TCP
SPT=80 DPT=1324 WINDOW=16080 RES=0x00 ACK URGP=0
Aug 4 09:23:12 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=66.193.183.25
DST=192.168.15.5 LEN=48 TOS=0x08 PREC=0x00 TTL=127 ID=12779 DF PROTO=TCP
SPT=4862 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 09:23:15 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=66.193.183.25
DST=192.168.15.5 LEN=48 TOS=0x08 PREC=0x00 TTL=127 ID=12782 DF PROTO=TCP
SPT=4862 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 09:23:21 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=66.193.183.25
DST=192.168.15.5 LEN=48 TOS=0x08 PREC=0x00 TTL=127 ID=12783 DF PROTO=TCP
SPT=4862 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 10:56:09 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.2 DST=66.193.183.5
LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=26841 DF PROTO=TCP SPT=3718 DPT=20
WINDOW=64240 RES=0x00 SYN URGP=0
Aug 4 10:56:12 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.2 DST=66.193.183.5
LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=26844 DF PROTO=TCP SPT=3718 DPT=20
WINDOW=64240 RES=0x00 SYN URGP=0
Aug 4 10:56:18 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.2 DST=66.193.183.5
LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=26854 DF PROTO=TCP SPT=3718 DPT=20
WINDOW=64240 RES=0x00 SYN URGP=0
Aug 4 10:57:44 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.2 DST=66.193.183.5
LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=26881 DF PROTO=TCP SPT=3723 DPT=20
WINDOW=64240 RES=0x00 SYN URGP=0
Aug 4 10:57:47 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.2 DST=66.193.183.5
LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=26882 DF PROTO=TCP SPT=3723 DPT=20
WINDOW=64240 RES=0x00 SYN URGP=0
Aug 4 10:57:53 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.2 DST=66.193.183.5
LEN=48 TOS=0x08 PREC=0x00 TTL=128 ID=26883 DF PROTO=TCP SPT=3723 DPT=20
WINDOW=64240 RES=0x00 SYN URGP=0
Aug 4 11:32:12 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=66.193.183.25
DST=192.168.15.222 LEN=48 TOS=0x10 PREC=0x00 TTL=127 ID=32876 DF PROTO=TCP
SPT=4162 DPT=21 WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 11:32:12 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=66.193.183.25
DST=192.168.15.32 LEN=48 TOS=0x10 PREC=0x00 TTL=127 ID=32877 DF PROTO=TCP
SPT=4163 DPT=22 WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 11:32:13 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=66.193.183.25
DST=192.168.15.11 LEN=48 TOS=0x08 PREC=0x00 TTL=127 ID=32935 DF PROTO=TCP
SPT=4221 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 11:34:29 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.25 DST=66.193.183.5
LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=34544 DF PROTO=TCP SPT=3846 DPT=1
WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 11:34:29 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.25 DST=66.193.183.5
LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=34545 DF PROTO=TCP SPT=3847 DPT=2
WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 11:34:29 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.25 DST=66.193.183.5
LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=34546 DF PROTO=TCP SPT=3848 DPT=3
WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 11:34:29 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.25 DST=66.193.183.5
LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=34547 DF PROTO=TCP SPT=3849 DPT=4
WINDOW=16384 RES=0x00 SYN URGP=0
Aug 4 11:34:29 net2all:DROP:IN=eth0 OUT= SRC=66.193.183.25 DST=66.193.183.5
LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=34548 DF PROTO=TCP SPT=3850 DPT=5
WINDOW=16384 RES=0x00 SYN URGP=0
NAT Table
Chain OUTPUT (policy ACCEPT 4 packets, 310 bytes)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:1723 to:192.168.15.5
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:80 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:443 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:21 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:25 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:110 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:8443 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:21 to:192.168.15.222
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.10 tcp dpt:80 to:192.168.15.9
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.10 tcp dpt:443 to:192.168.15.9
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.9 tcp dpt:80 to:192.168.15.8
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:6000 to:192.168.15.31
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:8080 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:8021 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.11 tcp dpt:80 to:192.168.15.4
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.11 tcp dpt:443 to:192.168.15.4
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:22 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.12 tcp dpt:80 to:192.168.15.223
Chain POSTROUTING (policy ACCEPT 22 packets, 1078 bytes)
pkts bytes target prot opt in out source
destination
16 748 eth0_masq all -- * eth0 0.0.0.0/0
0.0.0.0/0
Chain PREROUTING (policy ACCEPT 2483 packets, 120K bytes)
pkts bytes target prot opt in out source
destination
787 38683 net_dnat all -- eth0 * 0.0.0.0/0
0.0.0.0/0
16 861 loc_dnat all -- eth1 * 0.0.0.0/0
0.0.0.0/0
Chain eth0_masq (1 references)
pkts bytes target prot opt in out source
destination
2 126 MASQUERADE all -- * * 192.168.15.0/24
0.0.0.0/0
0 0 MASQUERADE all -- * * 169.254.0.0/16
0.0.0.0/0
Chain loc_dnat (1 references)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:1723 to:192.168.15.5
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:80 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:443 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:21 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:25 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:110 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:8443 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:21 to:192.168.15.222
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.10 tcp dpt:80 to:192.168.15.9
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.10 tcp dpt:443 to:192.168.15.9
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.9 tcp dpt:80 to:192.168.15.8
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:6000 to:192.168.15.31
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:8080 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:8021 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.11 tcp dpt:80 to:192.168.15.4
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.11 tcp dpt:443 to:192.168.15.4
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:22 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.12 tcp dpt:80 to:192.168.15.223
Chain net_dnat (1 references)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:1723 to:192.168.15.5
4 192 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:80 to:192.168.15.11
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:80 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:443 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:21 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:25 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:110 to:192.168.15.7
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.7 tcp dpt:8443 to:192.168.15.7
1 48 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:21 to:192.168.15.222
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.10 tcp dpt:80 to:192.168.15.9
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.10 tcp dpt:443 to:192.168.15.9
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.9 tcp dpt:80 to:192.168.15.8
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:6000 to:192.168.15.31
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:8080 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:8021 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.11 tcp dpt:80 to:192.168.15.4
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.11 tcp dpt:443 to:192.168.15.4
1 48 DNAT tcp -- * * 0.0.0.0/0
66.193.183.5 tcp dpt:22 to:192.168.15.32
0 0 DNAT tcp -- * * 0.0.0.0/0
66.193.183.12 tcp dpt:80 to:192.168.15.223
Mangle Table
Chain FORWARD (policy ACCEPT 21 packets, 1098 bytes)
pkts bytes target prot opt in out source
destination
18 954 tcfor all -- * * 0.0.0.0/0
0.0.0.0/0
Chain INPUT (policy ACCEPT 2694 packets, 137K bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 1953 packets, 214K bytes)
pkts bytes target prot opt in out source
destination
242 145K outtos all -- * * 0.0.0.0/0
0.0.0.0/0
242 145K tcout all -- * * 0.0.0.0/0
0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 1971 packets, 215K bytes)
pkts bytes target prot opt in out source
destination
Chain PREROUTING (policy ACCEPT 2715 packets, 138K bytes)
pkts bytes target prot opt in out source
destination
1007 55231 pretos all -- * * 0.0.0.0/0
0.0.0.0/0
1007 55231 tcpre all -- * * 0.0.0.0/0
0.0.0.0/0
Chain outtos (1 references)
pkts bytes target prot opt in out source
destination
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:20 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:20 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:80 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:80 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:443 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:443 TOS set 0x08
Chain pretos (1 references)
pkts bytes target prot opt in out source
destination
1 48 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:22 TOS set 0x10
1 48 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:20 TOS set 0x08
1 48 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:20 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:80 TOS set 0x08
10 480 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:80 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:443 TOS set 0x08
1 48 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:443 TOS set 0x08
Chain tcfor (1 references)
pkts bytes target prot opt in out source
destination
Chain tcout (1 references)
pkts bytes target prot opt in out source
destination
Chain tcpre (1 references)
pkts bytes target prot opt in out source
destination
tcp 6 114 TIME_WAIT src=192.168.15.31 dst=192.168.15.1 sport=4635
dport=10000 packets=33 bytes=2796 src=192.168.15.1 dst=192.168.15.31
sport=10000 dport=4635 packets=35 bytes=24746 [ASSURED] mark=0 use=1
tcp 6 431999 ESTABLISHED src=192.168.15.31 dst=192.168.15.1 sport=4633
dport=10000 packets=78 bytes=4971 src=192.168.15.1 dst=192.168.15.31
sport=10000 dport=4633 packets=83 bytes=66690 [ASSURED] mark=0 use=1
udp 17 0 src=192.168.15.31 dst=64.132.94.250 sport=3712 dport=53
packets=3 bytes=189 [UNREPLIED] src=64.132.94.250 dst=66.193.183.5 sport=53
dport=3712 packets=0 bytes=0 mark=0 use=1
tcp 6 112 TIME_WAIT src=192.168.15.31 dst=192.168.15.1 sport=4632
dport=10000 packets=25 bytes=1725 src=192.168.15.1 dst=192.168.15.31
sport=10000 dport=4632 packets=27 bytes=17736 [ASSURED] mark=0 use=1
tcp 6 1 CLOSE src=192.168.15.31 dst=192.168.15.1 sport=4631 dport=10000
packets=5 bytes=286 src=192.168.15.1 dst=192.168.15.31 sport=10000
dport=4631 packets=4 bytes=867 [ASSURED] mark=0 use=1
tcp 6 116 TIME_WAIT src=192.168.15.31 dst=192.168.15.1 sport=4634
dport=10000 packets=39 bytes=3392 src=192.168.15.1 dst=192.168.15.31
sport=10000 dport=4634 packets=43 bytes=30319 [ASSURED] mark=0 use=1
udp 17 16 src=66.193.183.5 dst=216.136.95.2 sport=32770 dport=53
packets=2 bytes=142 [UNREPLIED] src=216.136.95.2 dst=66.193.183.5 sport=53
dport=32770 packets=0 bytes=0 mark=0 use=1
tcp 6 1 CLOSE src=192.168.15.31 dst=192.168.15.1 sport=4630 dport=10000
packets=5 bytes=286 src=192.168.15.1 dst=192.168.15.31 sport=10000
dport=4630 packets=4 bytes=867 [ASSURED] mark=0 use=1
udp 17 11 src=66.193.183.5 dst=64.132.94.250 sport=32769 dport=53
packets=2 bytes=142 [UNREPLIED] src=64.132.94.250 dst=66.193.183.5 sport=53
dport=32769 packets=0 bytes=0 mark=0 use=1
tcp 6 1 CLOSE src=192.168.15.31 dst=192.168.15.1 sport=4629 dport=10000
packets=5 bytes=310 src=192.168.15.1 dst=192.168.15.31 sport=10000
dport=4629 packets=4 bytes=867 [ASSURED] mark=0 use=1
udp 17 0 src=192.168.15.31 dst=216.136.95.2 sport=3712 dport=53
packets=3 bytes=189 [UNREPLIED] src=216.136.95.2 dst=66.193.183.5 sport=53
dport=3712 packets=0 bytes=0 mark=0 use=1
tcp 6 431993 ESTABLISHED src=192.168.15.31 dst=192.168.15.1 sport=4636
dport=10000 packets=12 bytes=1453 src=192.168.15.1 dst=192.168.15.31
sport=10000 dport=4636 packets=12 bytes=5656 [ASSURED] mark=0 use=1
________________________________________
Chip Burke
________________________________________
-----Original Message-----
From: shorewall-users-admin@lists.sourceforge.net
[mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep
Sent: Thursday, August 04, 2005 11:46 AM
To: shorewall-users@lists.sourceforge.net
Subject: Re: [Shorewall-users] DNAT not working
Chip Burke wrote:> Eth1 is indeed the internal interface, but I have just tried this with
> separate switches and get the same results. I am not hip to ARP caching as
I> have never had to deal with this on any firewall before. (Until now I have
> always used PIX or Watchguard type appliances.) Is there some ARP cache
> config I need to do? As it stands now, my ARP cache config file is empty
> except for the comments that come in it.
There is nothing that I know of that can cause external traffic to enter
your internal interface except physical cabling/configuration problems (or
confusion over which interface is which).
-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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
I tried setting it to net with no luck. I will just put in a help request like Tom said to and rebuild it. I was on 1.4.8, but let me see where I get with 2.x . Thanks for all of your help! ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Stephen Carville Sent: Thursday, August 04, 2005 12:13 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working On Thu, 4 Aug 2005, Chip Burke wrote:> I am trying to setup what I think is pretty straight forward DNAT rulesand> they always fail. Below is the rule I have and the log entry I get. I read > the FAQ and have checked the gateway address and all that stuff, but it > still gets rejected. I am a bit confused by it showing in the log that IN > and OUT are both eth1. I have checked 50 times and the interfaces are > configured properly. (So far as I can tell.) Any ideas? > > > > Rule: > > DNAT all loc:192.168.15.5 tcp http - > 66.193.183.5I''d suggest changing ''all'' in the above rule to whatever you call your external interface in zones. For some reason your external traffic appears to be entering via eth1 then is leaving via eth1 to your internal network. This should not be happening and indicates a serious misconfiguration. Use tethereal or tcpdump to verify this is happenng. You''re not trying to use the same physical port for both external and internal traffic are you? Even if they have different subinterfaces this is a very bad idea on any firewall setup. Try clearing the arp cache on your switch. Then from the switch, ping both the external address of your firewall and the internal address. Check the arp cache. Are the MAC addreses the same or different?> > > Log message: > > > > Aug 4 09:23:21 firewall kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 > SRC=66.193.183.25 DST=192.168.15.5 LEN=48 TOS=0x08 PREC=0x00 TTL=127 > ID=12783 DF PROTO=TCP SPT=4862 DPT=80 WINDOW=16384 RES=0x00 SYN URGP=0 > > > > Thanks! > > > > ________________________________________ > Chip Burke > > ________________________________________ > > > >------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:> I am pretty much bewildered at this point. Everything else works.... > masquerade, ports open to the firewall itself. But DNAT doesn''t work at all. > Now it is not even logging the same things as before. It doesn''t seem to log > any DNAT activity. I am 100% certain I have the interfaces connected > correctly. Right now I have torn the firewall out and put it in test > environment with a different hub on either interface. Here is the IPTables > output. I know it is a lot, but I am hoping someone can find something > goofed up in one of the chains that I have missed. >a) In the future, please include the output of "shorewall status" *as an attachment* as requested on the support page. Otherwise, your mailer folds it into a pretzel. b) Please change the "all" SOURCE in your DNAT rules to "net" as recommended by Stephen Carville. If you *really* want to redirect requests from your local network back to the server in your local network (gag, barf), then please follow the instructions in Shorewall FAQ #2 (you need to add the "routeback" option to your entry for ''eth1'' in /etc/shorewall/interfaces and you need to masquerade this "routeback" traffic with an entry in /etc/shorewall/masq -- it''s a horrible disgusting hack that is much better avoided by using split DNS). -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
Sorry. Mental note for next time. However, I am noticing that when I start Shorewall and it is "Determining Hosts in Zones", each zone shows up with 0.0.0.0/0 as the address. The interfaces all have static IPs, so it should find it. Is there something I have missed here perhaps? I really appreciate your patience as I am pretty much a newbie in the world of OpenSourse, so I am slowly learning the etiquette. ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, August 04, 2005 12:53 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Chip Burke wrote:> I am pretty much bewildered at this point. Everything else works.... > masquerade, ports open to the firewall itself. But DNAT doesn''t work atall.> Now it is not even logging the same things as before. It doesn''t seem tolog> any DNAT activity. I am 100% certain I have the interfaces connected > correctly. Right now I have torn the firewall out and put it in test > environment with a different hub on either interface. Here is the IPTables > output. I know it is a lot, but I am hoping someone can find something > goofed up in one of the chains that I have missed. >a) In the future, please include the output of "shorewall status" *as an attachment* as requested on the support page. Otherwise, your mailer folds it into a pretzel. b) Please change the "all" SOURCE in your DNAT rules to "net" as recommended by Stephen Carville. If you *really* want to redirect requests from your local network back to the server in your local network (gag, barf), then please follow the instructions in Shorewall FAQ #2 (you need to add the "routeback" option to your entry for ''eth1'' in /etc/shorewall/interfaces and you need to masquerade this "routeback" traffic with an entry in /etc/shorewall/masq -- it''s a horrible disgusting hack that is much better avoided by using split DNS). -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:> Sorry. Mental note for next time. However, I am noticing that when I start > Shorewall and it is "Determining Hosts in Zones", each zone shows up with > 0.0.0.0/0 as the address. The interfaces all have static IPs, so it should > find it. Is there something I have missed here perhaps? > > I really appreciate your patience as I am pretty much a newbie in the world > of OpenSourse, so I am slowly learning the etiquette. >It''s considered good form to look in the FAQ before asking busy people to interrupt their day to answer your newbie question -- your question above is Shorewall FAQ #9 (http://shorewall.net/FAQ.htm#faq9). -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
Tom Eastep wrote on 04/08/2005 14:43:43:> Chip Burke wrote: > > Sorry. Mental note for next time. However, I am noticing that when Istart> > Shorewall and it is "Determining Hosts in Zones", each zone shows upwith> > 0.0.0.0/0 as the address. The interfaces all have static IPs, so itshould> > find it. Is there something I have missed here perhaps? > > > > I really appreciate your patience as I am pretty much a newbie in theworld> > of OpenSourse, so I am slowly learning the etiquette. > > > > It''s considered good form to look in the FAQ before asking busy peopleto> interrupt their day to answer your newbie question -- your questionabove is> Shorewall FAQ #9 (http://shorewall.net/FAQ.htm#faq9). >Tom, I think you''re spending too much time in the users list again... ;-) cheers, Eduardo Ferreira
Eduardo Ferreira wrote:>> > Tom, I think you''re spending too much time in the users list again... ;-)Yes -- I didn''t anticipate that Chip''s question was going to become so involved :-) Feel free to take over handling this thread, Eduardo; I won''t object. -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
Okay, I totally yanked out 1.4.8 and put in the latest, greatest 2.4 release because support no longer is happening for the older stuff. I simplified the DNAT rules to a single forward to simplify troubleshooting and worry about the other IPs and forwards later. I have also read the help docs closely so as to hopefully not step on any more toes or ask dumb obvious questions. I attached my status output. I am also going to try to give as much detail as I can here as to my test environment setup. I have a RedHat FC4 box with two interfaces: Eth0: the public interface in the "pub" zone with IP 66.193.183.5/26 Eth0:0 66.193.183.7 Eth0:1 66.193.183.10 Eth0:2 66.193.183.9 Eth0:3 66.193.183.11 Eth1: the private interface in the "priv" zone with IP 192.168.15.1/24 I have two separate hubs for the public and private interface. On the public hub I have the public interface of the firewall machine and my laptop, nothing else. My laptop I have assigned address 66.193.183.25/26. On the private network I have a web server at 192.168.15.11 that I am trying to forward all connections to port 80 on 66.193.183.5 to. I know the web server works because I can connect to it on the private network using 192.168.15.11. I am masquerading the private network. Pings to the public interface work okay. Outgoing masquerade traffic works okay. Incoming traffic that terminates at the firewall works okay (SSH specifically). Thanks again for your kind assistance and patience, ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, August 04, 2005 12:53 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Chip Burke wrote:> I am pretty much bewildered at this point. Everything else works.... > masquerade, ports open to the firewall itself. But DNAT doesn''t work atall.> Now it is not even logging the same things as before. It doesn''t seem tolog> any DNAT activity. I am 100% certain I have the interfaces connected > correctly. Right now I have torn the firewall out and put it in test > environment with a different hub on either interface. Here is the IPTables > output. I know it is a lot, but I am hoping someone can find something > goofed up in one of the chains that I have missed. >a) In the future, please include the output of "shorewall status" *as an attachment* as requested on the support page. Otherwise, your mailer folds it into a pretzel. b) Please change the "all" SOURCE in your DNAT rules to "net" as recommended by Stephen Carville. If you *really* want to redirect requests from your local network back to the server in your local network (gag, barf), then please follow the instructions in Shorewall FAQ #2 (you need to add the "routeback" option to your entry for ''eth1'' in /etc/shorewall/interfaces and you need to masquerade this "routeback" traffic with an entry in /etc/shorewall/masq -- it''s a horrible disgusting hack that is much better avoided by using split DNS). -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
Chip wrote on 04/08/2005 15:28:15:> Okay, I totally yanked out 1.4.8 and put in the latest, greatest 2.4release> because support no longer is happening for the older stuff.very good.> I simplified the > DNAT rules to a single forward to simplify troubleshooting and worryabout> the other IPs and forwards later.Ok...> > I have a RedHat FC4 box with two interfaces: > > Eth0: the public interface in the "pub" zone with IP 66.193.183.5/26 > Eth0:0 66.193.183.7 > Eth0:1 66.193.183.10 > Eth0:2 66.193.183.9 > Eth0:3 66.193.183.11 > Eth1: the private interface in the "priv" zone with IP 192.168.15.1/24 > > I have two separate hubs for the public and private interface. On thepublic> hub I have the public interface of the firewall machine and my laptop, > nothing else. My laptop I have assigned address 66.193.183.25/26. >Isn''t this the address of your logged packet? see bellow...> On the private network I have a web server at 192.168.15.11 that I amtrying> to forward all connections to port 80 on 66.193.183.5 to. I know the web > server works because I can connect to it on the private network using > 192.168.15.11. > > I am masquerading the private network. > > Pings to the public interface work okay. Outgoing masquerade trafficworks> okay. Incoming traffic that terminates at the firewall works okay (SSH > specifically).I think we need your configuration files. Can you send us at least your zones/interfaces/policy/rules/nat/masq files? tks, -- Eduardo Ferreira
Certainly, they are attached. ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Eduardo Ferreira Sent: Thursday, August 04, 2005 2:47 PM To: shorewall-users@lists.sourceforge.net Subject: RE: [Shorewall-users] DNAT not working Chip wrote on 04/08/2005 15:28:15:> Okay, I totally yanked out 1.4.8 and put in the latest, greatest 2.4release> because support no longer is happening for the older stuff.very good.> I simplified the > DNAT rules to a single forward to simplify troubleshooting and worry about > the other IPs and forwards later.Ok...> > I have a RedHat FC4 box with two interfaces: > > Eth0: the public interface in the "pub" zone with IP 66.193.183.5/26 > Eth0:0 66.193.183.7 > Eth0:1 66.193.183.10 > Eth0:2 66.193.183.9 > Eth0:3 66.193.183.11 > Eth1: the private interface in the "priv" zone with IP 192.168.15.1/24 > > I have two separate hubs for the public and private interface. On thepublic> hub I have the public interface of the firewall machine and my laptop, > nothing else. My laptop I have assigned address 66.193.183.25/26. >Isn''t this the address of your logged packet? see bellow...> On the private network I have a web server at 192.168.15.11 that I amtrying> to forward all connections to port 80 on 66.193.183.5 to. I know the web > server works because I can connect to it on the private network using > 192.168.15.11. > > I am masquerading the private network. > > Pings to the public interface work okay. Outgoing masquerade traffic works > okay. Incoming traffic that terminates at the firewall works okay (SSH > specifically).I think we need your configuration files. Can you send us at least your zones/interfaces/policy/rules/nat/masq files? tks, -- Eduardo Ferreira
Chip Burke wrote:> Certainly, they are attached. >And that configuration seems to be working fine (at least your web server asks me to authenticate when I try to browse http://66.193.183.5/). -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
Chip Burke wrote:> Certainly, they are attached.In rules you have: DNAT pub priv:192.168.15.11 tcp http - 66.193.183.5 $ telnet 66.193.183.5 80 Trying 66.193.183.5... Connected to 66.193.183.5. Escape character is ''^]''. GET / HTTP/1.0 HTTP/1.1 401 Authorization Required Date: Thu, 04 Aug 2005 19:12:05 GMT Server: Apache/2.0.54 (Fedora) WWW-Authenticate: Basic realm="InnovaScan Access" Content-Length: 493 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>401 Authorization Required</title> </head><body> <h1>Authorization Required</h1> <p>This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn''t understand how to supply the credentials required.</p> <hr> <address>Apache/2.0.54 (Fedora) Server at nagios.innova-partners.com Port 80</address> </body></html> Connection closed by foreign host. Do you have a web server running on the firewall? If not, it looks like you are getting forwarded.> > > ________________________________________ > Chip Burke > > ________________________________________ > > -----Original Message----- > *From:* shorewall-users-admin@lists.sourceforge.net > [mailto:shorewall-users-admin@lists.sourceforge.net] *On Behalf Of > *Eduardo Ferreira > *Sent:* Thursday, August 04, 2005 2:47 PM > *To:* shorewall-users@lists.sourceforge.net > *Subject:* RE: [Shorewall-users] DNAT not working > > > > > Chip wrote on 04/08/2005 15:28:15: > >> Okay, I totally yanked out 1.4.8 and put in the latest, greatest 2.4 > release >> because support no longer is happening for the older stuff. > very good. > >> I simplified the >> DNAT rules to a single forward to simplify troubleshooting and worry about >> the other IPs and forwards later. > Ok... > >> >> I have a RedHat FC4 box with two interfaces: >> >> Eth0: the public interface in the "pub" zone with IP 66.193.183.5/26 >> Eth0:0 66.193.183.7 >> Eth0:1 66.193.183.10 >> Eth0:2 66.193.183.9 >> Eth0:3 66.193.183.11 >> Eth1: the private interface in the "priv" zone with IP 192.168.15.1/24 >> >> I have two separate hubs for the public and private interface. On the > public >> hub I have the public interface of the firewall machine and my laptop, >> nothing else. My laptop I have assigned address 66.193.183.25/26. >> > Isn''t this the address of your logged packet? see bellow... > >> On the private network I have a web server at 192.168.15.11 that I am > trying >> to forward all connections to port 80 on 66.193.183.5 to. I know the web >> server works because I can connect to it on the private network using >> 192.168.15.11. >> >> I am masquerading the private network. >> >> Pings to the public interface work okay. Outgoing masquerade traffic works >> okay. Incoming traffic that terminates at the firewall works okay (SSH >> specifically). > I think we need your configuration files. Can you send us at least your > zones/interfaces/policy/rules/nat/masq files? > > tks, > > -- > Eduardo Ferreira >-- Stephen Carville <stephen@totalflood.com> Unix and Network Admin Nationwide Totalflood 6033 W. Century Blvd Los Angeles, CA 90045 310-342-3602 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Tom Eastep wrote on 04/08/2005 16:09:52:> Chip Burke wrote: > > Certainly, they are attached. > > > > And that configuration seems to be working fine (at least your webserver> asks me to authenticate when I try to browse http://66.193.183.5/). > > -Tom > --Me too, But I noticed he changed the DNAT rule replacing ''all'' by ''pub'' in the source column. Chip: The log you sent in your first post is still happening? It happens when you try to access your browser from your laptop in the pub zone? If so, again, is your VLAN well configured? If so, is your laptop in the correct VLAN? cheers, -- Eduardo Ferreira
Stephen, I have all of this isolated off in a test environment. You are hitting our old production firewall which is what this will be replacing. ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Stephen Carville Sent: Thursday, August 04, 2005 3:15 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Chip Burke wrote:> Certainly, they are attached.In rules you have: DNAT pub priv:192.168.15.11 tcp http - 66.193.183.5 $ telnet 66.193.183.5 80 Trying 66.193.183.5... Connected to 66.193.183.5. Escape character is ''^]''. GET / HTTP/1.0 HTTP/1.1 401 Authorization Required Date: Thu, 04 Aug 2005 19:12:05 GMT Server: Apache/2.0.54 (Fedora) WWW-Authenticate: Basic realm="InnovaScan Access" Content-Length: 493 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>401 Authorization Required</title> </head><body> <h1>Authorization Required</h1> <p>This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn''t understand how to supply the credentials required.</p> <hr> <address>Apache/2.0.54 (Fedora) Server at nagios.innova-partners.com Port 80</address> </body></html> Connection closed by foreign host. Do you have a web server running on the firewall? If not, it looks like you are getting forwarded.> > > ________________________________________ > Chip Burke > > ________________________________________ > > -----Original Message----- > *From:* shorewall-users-admin@lists.sourceforge.net > [mailto:shorewall-users-admin@lists.sourceforge.net] *On Behalf Of > *Eduardo Ferreira > *Sent:* Thursday, August 04, 2005 2:47 PM > *To:* shorewall-users@lists.sourceforge.net > *Subject:* RE: [Shorewall-users] DNAT not working > > > > > Chip wrote on 04/08/2005 15:28:15: > >> Okay, I totally yanked out 1.4.8 and put in the latest, greatest 2.4 > release >> because support no longer is happening for the older stuff. > very good. > >> I simplified the >> DNAT rules to a single forward to simplify troubleshooting and worryabout>> the other IPs and forwards later. > Ok... > >> >> I have a RedHat FC4 box with two interfaces: >> >> Eth0: the public interface in the "pub" zone with IP 66.193.183.5/26 >> Eth0:0 66.193.183.7 >> Eth0:1 66.193.183.10 >> Eth0:2 66.193.183.9 >> Eth0:3 66.193.183.11 >> Eth1: the private interface in the "priv" zone with IP 192.168.15.1/24 >> >> I have two separate hubs for the public and private interface. On the > public >> hub I have the public interface of the firewall machine and my laptop, >> nothing else. My laptop I have assigned address 66.193.183.25/26. >> > Isn''t this the address of your logged packet? see bellow... > >> On the private network I have a web server at 192.168.15.11 that I am > trying >> to forward all connections to port 80 on 66.193.183.5 to. I know the web >> server works because I can connect to it on the private network using >> 192.168.15.11. >> >> I am masquerading the private network. >> >> Pings to the public interface work okay. Outgoing masquerade trafficworks>> okay. Incoming traffic that terminates at the firewall works okay (SSH >> specifically). > I think we need your configuration files. Can you send us at least your > zones/interfaces/policy/rules/nat/masq files? > > tks, > > -- > Eduardo Ferreira >-- Stephen Carville <stephen@totalflood.com> Unix and Network Admin Nationwide Totalflood 6033 W. Century Blvd Los Angeles, CA 90045 310-342-3602 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
No, forget everything from earlier. There are no VLANs. I have stripped this down to remove all the variables. I am running two separate hubs in a test environment. I am not about to drop this into production until I can get it to work on the bench. So I have two little 4 port hubs, one for each interface. Time for ASCII art Laptop ------ Hub -------- eth0 Linux box eth1 ------ hub -------- Web server Laptop: 66.193.183.25 Eth0: 66.193.183.5 Eth1: 192.168.15.1 Web server: 192.168.15.11 This is not connected to the net yet, so if you try connecting to any of the addresses in my config, it will of course work because it is going through another firewall entirely which this is supposed to replace. Thanks for everyone''s input. ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Eduardo Ferreira Sent: Thursday, August 04, 2005 3:19 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Tom Eastep wrote on 04/08/2005 16:09:52:> Chip Burke wrote: > > Certainly, they are attached. > > > > And that configuration seems to be working fine (at least your web server > asks me to authenticate when I try to browse http://66.193.183.5/). > > -Tom > --Me too, But I noticed he changed the DNAT rule replacing ''all'' by ''pub'' in the source column. Chip: The log you sent in your first post is still happening? It happens when you try to access your browser from your laptop in the pub zone? If so, again, is your VLAN well configured? If so, is your laptop in the correct VLAN? cheers, -- Eduardo Ferreira ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:> No, forget everything from earlier. There are no VLANs. I have stripped this > down to remove all the variables. I am running two separate hubs in a test > environment. I am not about to drop this into production until I can get it > to work on the bench. So I have two little 4 port hubs, one for each > interface. Time for ASCII art… > > > > Laptop ------ Hub -------- eth0 – Linux box – eth1 ------ > hub -------- Web server > > > Laptop: 66.193.183.25 > Eth0: 66.193.183.5 > Eth1: 192.168.15.1 > Web server: 192.168.15.11 > > This is not connected to the net yet, so if you try connecting to any of the > addresses in my config, it will of course work because it is going through > another firewall entirely which this is supposed to replace. > > Thanks for everyone''s input. >Please follow the DNAT debugging tips in FAQs 1a and 1b. -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
Chip: Is your test enviroment totally seperate? ie, seperate test webserver? Or is this webserver really on the local lan, if so, is the webserver''s default gateway the shorewall box? Jerry ----- Original Message ----- From: "Chip Burke" <cburke@innova-partners.com> To: <shorewall-users@lists.sourceforge.net> Sent: Thursday, August 04, 2005 14:30 Subject: RE: [Shorewall-users] DNAT not working No, forget everything from earlier. There are no VLANs. I have stripped this down to remove all the variables. I am running two separate hubs in a test environment. I am not about to drop this into production until I can get it to work on the bench. So I have two little 4 port hubs, one for each interface. Time for ASCII art. Laptop ------ Hub -------- eth0 - Linux box - eth1 ------ hub -------- Web server Laptop: 66.193.183.25 Eth0: 66.193.183.5 Eth1: 192.168.15.1 Web server: 192.168.15.11 This is not connected to the net yet, so if you try connecting to any of the addresses in my config, it will of course work because it is going through another firewall entirely which this is supposed to replace. Thanks for everyone''s input. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote on 04/08/2005 16:30:37:> No, forget everything from earlier. There are no VLANs. I have strippedthis> down to remove all the variables. I am running two separate hubs in atest> environment. I am not about to drop this into production until I can getit> to work on the bench. So I have two little 4 port hubs, one for each > interface. Time for ASCII art? > > > > Laptop ------ Hub -------- eth0 ? Linux box ? eth1 ------ > hub -------- Web server > > > Laptop: 66.193.183.25 > Eth0: 66.193.183.5 > Eth1: 192.168.15.1 > Web server: 192.168.15.11 > > This is not connected to the net yet, so if you try connecting to any ofthe> addresses in my config, it will of course work because it is goingthrough> another firewall entirely which this is supposed to replace. > > Thanks for everyone''s input. >Well, I''m running out of ideas here. Have you tcpdumped the eth0 interface? What do you see? cheers, -- Eduardo Ferreira
I cower at your feet. There is was all along, I put in the wrong gateway IP on the firewall..... Well, if you don''t mind, I will try to help those around here even greener than I am to repay your kindness. :-) Thank you everyone! ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, August 04, 2005 3:36 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Chip Burke wrote:> No, forget everything from earlier. There are no VLANs. I have strippedthis> down to remove all the variables. I am running two separate hubs in a test > environment. I am not about to drop this into production until I can getit> to work on the bench. So I have two little 4 port hubs, one for each > interface. Time for ASCII art. > > > > Laptop ------ Hub -------- eth0 - Linux box - eth1 ------ > hub -------- Web server > > > Laptop: 66.193.183.25 > Eth0: 66.193.183.5 > Eth1: 192.168.15.1 > Web server: 192.168.15.11 > > This is not connected to the net yet, so if you try connecting to any ofthe> addresses in my config, it will of course work because it is going through > another firewall entirely which this is supposed to replace. > > Thanks for everyone''s input. >Please follow the DNAT debugging tips in FAQs 1a and 1b. -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Gentoo users might be interested in this article: http://gentoo-wiki.com/HOWTO_Shorewall_Firewall_IPsec_VPN_and_2.6_kernel Helpful contributions appreciated. Cheers ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Vieri Di Paola wrote:> Gentoo users might be interested in this article: > > http://gentoo-wiki.com/HOWTO_Shorewall_Firewall_IPsec_VPN_and_2.6_kernel > > Helpful contributions appreciated. >Thank you for your contribution, Vieri! -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
Reading the FAQ I am a bit confused. Do I put in a normal DNAT rule plus the DNAT in the FAQ? I.e. do I use DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69 AND DNAT net loc:192.168.1.5 tcp www - 130.151.100.69 Or do I only use the first rule. Yes yes, I know, this sucks and it is not the best way to go, but I am in a situation where I don''t have the ability to do a split DNS thing. However, if I were to put in a DMZ, would the URL www.domain.com work the same for external and internal clients? I read FAQ 2b and it seems the fix is just a variation on the one above. I am just trying to see if there is a way to avoid having to create a rule for each host I want to direct to be it in the DMZ or private network. Either way, I think I will end up creating a rule for each host in the firewall or creating a split DNS and having to create two records. Thanks folks, ________________________________________ Chip Burke ________________________________________ -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Thursday, August 04, 2005 12:53 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working b) Please change the "all" SOURCE in your DNAT rules to "net" as recommended by Stephen Carville. If you *really* want to redirect requests from your local network back to the server in your local network (gag, barf), then please follow the instructions in Shorewall FAQ #2 (you need to add the "routeback" option to your entry for ''eth1'' in /etc/shorewall/interfaces and you need to masquerade this "routeback" traffic with an entry in /etc/shorewall/masq -- it''s a horrible disgusting hack that is much better avoided by using split DNS). -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:> Reading the FAQ I am a bit confused. Do I put in a normal DNAT rule plus the > DNAT in the FAQ? I.e. do I use > > DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69 > > AND > > DNAT net loc:192.168.1.5 tcp www - 130.151.100.69 > > > Or do I only use the first rule.You need both -- or you can go back to using "all" in the SOURCE column of a single rule. You still need the masq (actually SNAT) entry in /etc/shorewall/masq and you need to set ''routeback'' on the internal interface. And all loc->loc traffic will undergo SNAT so it will look to the servers as if it came from the firewall (no accountability).> > Yes yes, I know, this sucks and it is not the best way to go, but I am in a > situation where I don''t have the ability to do a split DNS thing.You can''t run a DNS server on your firewall to serve your local hosts?????> However, > if I were to put in a DMZ, would the URL www.domain.com work the same for > external and internal clients? I read FAQ 2b and it seems the fix is just a > variation on the one above.One of the many reasons that I dislike NAT for Internet-accessible servers. I much prefer a DMZ using Proxy ARP as described in the Shorewall Setup Guide.> I am just trying to see if there is a way to > avoid having to create a rule for each host I want to direct to be it in the > DMZ or private network.You can use one-to-one NAT -- you still need ACCEPT rules for the traffic that you wish to accept, but again you can use a single rule with "all" in the SOURCE column.> Either way, I think I will end up creating a rule > for each host in the firewall or creating a split DNS and having to create > two records. >Yes -- the difference with the DNS solution is: a) Traffic from local hosts doesn''t appear to the servers to originate on the firewall. b) You are not redirecting traffic back out the same interface that it came in on. -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
>You need both -- or you can go back to using "all" in the SOURCE column ofa>single rule. You still need the masq (actually SNAT) entry in/etc/shorewall/masq and you need to set ''routeback'' on the internal>interface. And all loc->loc traffic will undergo SNAT so it will look tothe>servers as if it came from the firewall (no accountability).Hrm, the Apache logs won''t even log the proper IP from the browser? Yuck, I am going to have check into that. We run a lot of statistics against our server logs.>You can''t run a DNS server on your firewall to serve your local hosts?????We have Active Directory, so it would be a little hairy. We run a small hosting company, so there would be a zillion records to update too.>One of the many reasons that I dislike NAT for Internet-accessible servers. >I much prefer a DMZ using Proxy ARP as described in the Shorewall Setup >Guide.I think we need to do a bit of a redesign then. I will take your advice here as it looks to be a much better long term solution. Thanks so much Tom! ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:>>You need both -- or you can go back to using "all" in the SOURCE column of > a >>single rule. You still need the masq (actually SNAT) entry in > /etc/shorewall/masq and you need to set ''routeback'' on the internal >>interface. And all loc->loc traffic will undergo SNAT so it will look to > the >>servers as if it came from the firewall (no accountability). > > Hrm, the Apache logs won''t even log the proper IP from the browser?If the browser is in the ''loc'' zone, the IP logged by Apache will be that of the firewall -- Apache will log the proper IP for browsers in the ''net'' zone. -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
>You need both -- or you can go back to using "all" in the SOURCE column of >a >single rule. You still need the masq (actually SNAT) entry in >/etc/shorewall/masq and you need to set ''routeback'' on the internal >interface. And all loc->loc traffic will undergo SNAT so it will look to >the >servers as if it came from the firewall (no accountability).I tried this and it didn''t work. Here are the pertinent rules: Rules: DNAT all priv:192.168.15.11 tcp http - 66.193.183.5 Masq: Eth0 eth1 66.193.183.5 Eth1:192.168.15.11 eth1 192.168.15.1 tcp http Interface: Priv eth1 routeback You folks have been so helpful, do you have any windows I can wash or widgets to sort? I really like this project. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Chip Burke wrote:>>You need both -- or you can go back to using "all" in the SOURCE column of >>a >>single rule. You still need the masq (actually SNAT) entry in >>/etc/shorewall/masq and you need to set ''routeback'' on the internal >>interface. And all loc->loc traffic will undergo SNAT so it will look to >>the >>servers as if it came from the firewall (no accountability). > > > I tried this and it didn''t work. Here are the pertinent rules: > > Rules: > DNAT all priv:192.168.15.11 tcp http - 66.193.183.5 >Sorry -- brain cramp on my part. "all" does not enable intra-zone traffic so you will have to use separate rules. If 192.168.15.11 hosts lots of TCP services, you might do something like: /etc/shorewall/params: TCPSERVICES=http,https,ftp,smtp /etc/shorewall/rules: DNAT pub priv:192.168.15.11 tcp $TCPSERVICES DNAT priv priv:192.168.15.11 tcp $TCPSERVICES And please read http://www.shorewall.net/configuration_file_basics.htm before asking any questions about what I just showed you. -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
Great idea. Thanks for the tips on the macros. ________________________________________ Chip Burke -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: Friday, August 05, 2005 12:18 PM To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT not working Chip Burke wrote:>>You need both -- or you can go back to using "all" in the SOURCE column of >>a >>single rule. You still need the masq (actually SNAT) entry in >>/etc/shorewall/masq and you need to set ''routeback'' on the internal >>interface. And all loc->loc traffic will undergo SNAT so it will look to >>the >>servers as if it came from the firewall (no accountability). > > > I tried this and it didn''t work. Here are the pertinent rules: > > Rules: > DNAT all priv:192.168.15.11 tcp http - 66.193.183.5 >Sorry -- brain cramp on my part. "all" does not enable intra-zone traffic so you will have to use separate rules. If 192.168.15.11 hosts lots of TCP services, you might do something like: /etc/shorewall/params: TCPSERVICES=http,https,ftp,smtp /etc/shorewall/rules: DNAT pub priv:192.168.15.11 tcp $TCPSERVICES DNAT priv priv:192.168.15.11 tcp $TCPSERVICES And please read http://www.shorewall.net/configuration_file_basics.htm before asking any questions about what I just showed you. -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf