I have a firewall with 3 interfaces under CentOS5.5 and using Shorewall 4.4. There are multiple IP addresses on the external interfaces (2 of them - 1 to each of 2 different providers) and have one-to-one NAT setup on some of them for internal private IP systems. Initially this was all working great and all still works fine except for some of these NAT setups. After a couple of weeks (*no* change in the shorewall config), one of the forwarding stopped and connections were being rejected. Yesterday, another one did it. And then this morning, I noticed that one of the forwarding was going to the incorrect server on the private network! Attached is a copy of the output from ''shorewall dump''. I did a connection test from 208.69.72.26 to 38.116.137.22 on port 25 and the connection which should (and has been) forwarded to 192.168.0.212 failed - rejected. Did another test from the same IP to another NAT setup address 38.116.133.253 on port 25 and instead of a response from the configured NAT server at 192.168.0.213, I instead got the server at 192.168.0.212. As I noted, this was all working fine and then, one by one, they seem to stop working and I end up with the REJECT instead. Am not sure where to go from here since the config seems to be OK in my review of it and the shorewall docs - and it has been working fine. Any suggestions as to what to take a look at next or how to resolve this issue? Thanks! Chris ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On 04/05/2011 09:35 AM, Chris Stone wrote:> I have a firewall with 3 interfaces under CentOS5.5 and using > Shorewall 4.4. There are multiple IP addresses on the external > interfaces (2 of them - 1 to each of 2 different providers) and have > one-to-one NAT setup on some of them for internal private IP systems. > Initially this was all working great and all still works fine except > for some of these NAT setups. After a couple of weeks (*no* change in > the shorewall config), one of the forwarding stopped and connections > were being rejected. Yesterday, another one did it. And then this > morning, I noticed that one of the forwarding was going to the > incorrect server on the private network! > > Attached is a copy of the output from ''shorewall dump''. I did a > connection test from 208.69.72.26 to 38.116.137.22 on port 25 and the > connection which should (and has been) forwarded to 192.168.0.212 > failed - rejected. Did another test from the same IP to another NAT > setup address 38.116.133.253 on port 25 and instead of a response from > the configured NAT server at 192.168.0.213, I instead got the server > at 192.168.0.212. > > As I noted, this was all working fine and then, one by one, they seem > to stop working and I end up with the REJECT instead. Am not sure > where to go from here since the config seems to be OK in my review of > it and the shorewall docs - and it has been working fine.Check the REJECT messages and note the IN= interface. Is it the one you expect?> > Any suggestions as to what to take a look at next or how to resolve this issue?Check to be sure that your WAN network and LAN network aren''t bridged. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
Tom, On Tue, Apr 5, 2011 at 10:58 AM, Tom Eastep <teastep@shorewall.net> wrote:> Check the REJECT messages and note the IN= interface. Is it the one you > expect?No, actually, that''s showing the loc zone (eth1). I see some other REJECTS for 192.168.0.x to 192.168.0.x addresses in the log too. So, tried adding ''routeback'' to the the interfaces file for loc/eth1 and did some testing and it does seem to have resolved it. I''ve not had to add that option to the interfaces file for the loc zone before. Does this make sense to you as to what the issue may have been? Also seems very odd that it was working fine for a couple 3-4 months and then stopped without any changes in the shorewall config. Would expect it, if routeback missing was the problem, to not work from the beginning.... Will see if this ''fix'' persists I guess over the coming days....> Check to be sure that your WAN network and LAN network aren''t bridged.They are not. We have: LAN 192.168.0.x | eth1 | SHOREWALL FIREWALL --------------+----------------- eth0 eth2 | | | | AxisInternet Comcast Thanks! Chris ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On 04/05/2011 11:06 AM, Chris Stone wrote:> >> Check to be sure that your WAN network and LAN network aren''t bridged. > > They are not. We have:.. Mangled ASCII Art Deleted .. Then how do you explain these? Apr 5 10:23:05 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=22305 DF PROTO=TCP SPT=55032 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 Apr 5 10:23:07 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=6031 DF PROTO=TCP SPT=55042 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 Apr 5 10:23:08 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=35898 DF PROTO=TCP SPT=55056 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 eth1 is 192.168.0.1/24 so how is traffic from 208.69.72.26 entering the firewall on that interface??? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
Tom, On Tue, Apr 5, 2011 at 12:33 PM, Tom Eastep <teastep@shorewall.net> wrote:> Then how do you explain these? > > Apr 5 10:23:05 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 > DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=22305 DF PROTO=TCP > SPT=55032 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 > Apr 5 10:23:07 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 > DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=6031 DF PROTO=TCP > SPT=55042 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 > Apr 5 10:23:08 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 > DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=35898 DF PROTO=TCP > SPT=55056 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 > > eth1 is 192.168.0.1/24 so how is traffic from 208.69.72.26 entering the > firewall on that interface???Right, that is it''s IP. I was thinking those log entries referred to the NAT''d packet. It originally came in on eth0 where eth0:4 has the destination IP used of 38.116.137.22 that is setup as follows in /etc/shorewall/nat: #EXTERNAL INTERFACE INTERNAL ALL LOCAL # INTERFACES 38.116.137.22 eth0 192.168.0.212 Yes Yes So, it did not seem odd to have a packet with a source then of 208.69.72.26 going to 192.168.0.212 in eth1. Would also not have expected adding routeback to eth1 in /etc/shorewall/interfaces to have ''fixed'' this though, but now I am able to make this connection that was shown in the log with REJECT. It is still working now, but as noted, it was when first setup until a couple of months or so later it ''just stopped''. Thanks! Chris ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On 4/5/11 11:56 AM, Chris Stone wrote:> Tom, > > On Tue, Apr 5, 2011 at 12:33 PM, Tom Eastep <teastep@shorewall.net> wrote: >> Then how do you explain these? >> >> Apr 5 10:23:05 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 >> DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=22305 DF PROTO=TCP >> SPT=55032 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 >> Apr 5 10:23:07 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 >> DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=6031 DF PROTO=TCP >> SPT=55042 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 >> Apr 5 10:23:08 FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 >> DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=35898 DF PROTO=TCP >> SPT=55056 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 >> >> eth1 is 192.168.0.1/24 so how is traffic from 208.69.72.26 entering the >> firewall on that interface??? > > Right, that is it''s IP. I was thinking those log entries referred to > the NAT''d packet. It originally came in on eth0 where eth0:4 has the > destination IP used of 38.116.137.22 that is setup as follows in > /etc/shorewall/nat: > > #EXTERNAL INTERFACE INTERNAL ALL LOCAL > # INTERFACES > 38.116.137.22 eth0 192.168.0.212 Yes Yes > > So, it did not seem odd to have a packet with a source then of > 208.69.72.26 going to 192.168.0.212 in eth1.No but is is very odd to have the packet *entering* on that interface. Please see if you can find that packet in the log; it should have the Ethernet header included (Shorewall strips that part of the log message). That way, we can find out who sent it. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
Tom, On Tue, Apr 5, 2011 at 1:31 PM, Tom Eastep <teastep@shorewall.net> wrote:> No but is is very odd to have the packet *entering* on that interface.Yes, good point.> Please see if you can find that packet in the log; it should have the > Ethernet header included (Shorewall strips that part of the log > message). That way, we can find out who sent it.I''m sorry, what log are you referring to? Chris ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On 04/05/2011 02:30 PM, Chris Stone wrote:> Tom, > > On Tue, Apr 5, 2011 at 1:31 PM, Tom Eastep<teastep@shorewall.net> wrote: >> No but is is very odd to have the packet *entering* on that interface. > > Yes, good point. > >> Please see if you can find that packet in the log; it should have the >> Ethernet header included (Shorewall strips that part of the log >> message). That way, we can find out who sent it. > > I''m sorry, what log are you referring to?/var/log/messages -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
Tom, On Tue, Apr 5, 2011 at 3:41 PM, Tom Eastep <teastep@shorewall.net> wrote:>>> Please see if you can find that packet in the log; it should have the >>> Ethernet header included (Shorewall strips that part of the log >>> message). That way, we can find out who sent it. >> >> I''m sorry, what log are you referring to? > > /var/log/messagesOther than the shorewall messages that''s it. They are: Apr 5 08:24:09 vpn kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=54822 DF PROTO=TCP SPT=51690 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 Apr 5 10:23:05 vpn kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=22305 DF PROTO=TCP SPT=55032 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 Apr 5 10:23:07 vpn kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=6031 DF PROTO=TCP SPT=55042 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 Apr 5 10:23:08 vpn kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=208.69.72.26 DST=192.168.0.212 LEN=60 TOS=0x10 PREC=0x00 TTL=60 ID=35898 DF PROTO=TCP SPT=55056 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 Nothing else is logging traffic and shorewall, only for rejections and drops. Maybe I need to break it again and then try it while doing a packet capture? Or is there a way to get shorewall to dump the packet to the log file and include the ethernet header? Thanks! Chris ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev
On 4/5/11 3:25 PM, Chris Stone wrote: =0> > Nothing else is logging traffic and shorewall, only for rejections and > drops. Maybe I need to break it again and then try it while doing a > packet capture? Or is there a way to get shorewall to dump the packet > to the log file and include the ethernet header?You probably want to recreate and get a packet captuere. Shorewall does not have explicit control over inclusion of the Ethernet header. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Xperia(TM) PLAY It''s a major breakthrough. An authentic gaming smartphone on the nation''s most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev