Tom, On Tue, Apr 5, 2011 at 12:33 PM, Tom Eastep <[email protected]> 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 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
