Hi I am having a problem with a DNAT rule where the packets being
REJECT''d:
DNAT:info net priv:192.168.6.15 udp 5060
With the following appearing in the log:
Mar 6 11:59:30 ipcop kernel: Shorewall:net2fw:REJECT:IN=eth3
OUTMAC=00:09:6b:6e:48:e8:00:1d:20:fa:46:90:08:00 SRC=71.216.136.25
DST=67.138.129.66 LEN=629 TOS=0x10 PREC=0xA0 TTL=50 ID=28000 PROTO=UDP
SPT=5060 DPT=5060 LEN=609
Mar 6 11:59:34 ipcop kernel: Shorewall:net2fw:REJECT:IN=eth3
OUTMAC=00:09:6b:6e:48:e8:00:1d:20:fa:46:90:08:00 SRC=71.216.136.25
DST=67.138.129.66 LEN=629 TOS=0x10 PREC=0xA0 TTL=50 ID=28001 PROTO=UDP
SPT=5060 DPT=5060 LEN=609
I am confused why this is not working. Do I have typo somewhere or is
there a configuration problem? My other DNAT''s are working just fine.
Can some please help explain to me what the problem might be.
Thanks
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
dennis wrote:> Hi I am having a problem with a DNAT rule where the packets being REJECT''d: > > DNAT:info net priv:192.168.6.15 udp 5060 > > With the following appearing in the log: > > Mar 6 11:59:30 ipcop kernel: Shorewall:net2fw:REJECT:IN=eth3 OUT> MAC=00:09:6b:6e:48:e8:00:1d:20:fa:46:90:08:00 SRC=71.216.136.25 > DST=67.138.129.66 LEN=629 TOS=0x10 PREC=0xA0 TTL=50 ID=28000 PROTO=UDP > SPT=5060 DPT=5060 LEN=609 > Mar 6 11:59:34 ipcop kernel: Shorewall:net2fw:REJECT:IN=eth3 OUT> MAC=00:09:6b:6e:48:e8:00:1d:20:fa:46:90:08:00 SRC=71.216.136.25 > DST=67.138.129.66 LEN=629 TOS=0x10 PREC=0xA0 TTL=50 ID=28001 PROTO=UDP > SPT=5060 DPT=5060 LEN=609 > > > I am confused why this is not working. Do I have typo somewhere or is > there a configuration problem? My other DNAT''s are working just fine. > Can some please help explain to me what the problem might be.Most likely, you have networking starting before Shorewall during boot (this is normal). That leaves an opportunity for SIP packets to arrive between those start events (after networking is enabled but before the appropriate DNAT rule is in place). Given that the remote host always uses source port 5060, once a packet is received the connection tracking entry is in place. I recommend that you: a) Install the conntrack utility. b) Add this to your /etc/shorewall/started script: [ "$COMMAND" = start ] && conntrack -F Once you have installed the utility, simply runnng ''conntrack -F'' as root should correct the problem. Warning: That command flushes the connection tracking table so it may cause some existing connections to be disrupted. -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 \________________________________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Thanks for the help. I tried the command "conntrack -F" from the command line and it had no effect until I restarted shorewall too. I guess that was the part I was missing. So in general is this a race condition in iptables that will happend randomly from time to time? I am just trying to understand what is the root cause of this problem and if kernel or iptable upgrades will help solve the problem. Thanks again. Tom Eastep wrote:> dennis wrote: > >> Hi I am having a problem with a DNAT rule where the packets being REJECT''d: >> >> DNAT:info net priv:192.168.6.15 udp 5060 >> >> With the following appearing in the log: >> >> Mar 6 11:59:30 ipcop kernel: Shorewall:net2fw:REJECT:IN=eth3 OUT>> MAC=00:09:6b:6e:48:e8:00:1d:20:fa:46:90:08:00 SRC=71.216.136.25 >> DST=67.138.129.66 LEN=629 TOS=0x10 PREC=0xA0 TTL=50 ID=28000 PROTO=UDP >> SPT=5060 DPT=5060 LEN=609 >> Mar 6 11:59:34 ipcop kernel: Shorewall:net2fw:REJECT:IN=eth3 OUT>> MAC=00:09:6b:6e:48:e8:00:1d:20:fa:46:90:08:00 SRC=71.216.136.25 >> DST=67.138.129.66 LEN=629 TOS=0x10 PREC=0xA0 TTL=50 ID=28001 PROTO=UDP >> SPT=5060 DPT=5060 LEN=609 >> >> >> I am confused why this is not working. Do I have typo somewhere or is >> there a configuration problem? My other DNAT''s are working just fine. >> Can some please help explain to me what the problem might be. >> > > Most likely, you have networking starting before Shorewall during boot > (this is normal). That leaves an opportunity for SIP packets to arrive > between those start events (after networking is enabled but before the > appropriate DNAT rule is in place). Given that the remote host always > uses source port 5060, once a packet is received the connection tracking > entry is in place. > > I recommend that you: > > a) Install the conntrack utility. > b) Add this to your /etc/shorewall/started script: > > [ "$COMMAND" = start ] && conntrack -F > > Once you have installed the utility, simply runnng ''conntrack -F'' as > root should correct the problem. > > Warning: That command flushes the connection tracking table so it may > cause some existing connections to be disrupted. > > -Tom > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
dennis wrote:> So in general is this a race > condition in iptables that will happend randomly from time to time? I > am just trying to understand what is the root cause of this problem and > if kernel or iptable upgrades will help solve the problem.I can''t possibly answer that question -- you haven''t even told us what version of Shorewall you are running and if you are using Shorewall-shell or Shorewall-perl. Hint: /sbin/shorewall version -a -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 \________________________________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev