UDP DNAT help

UDP DNAT help

[Craig Packard]

[-- Attachment #1: Type: text/plain, Size: 3594 bytes --]

**********Original Post***********

From what I understand if I setup a DNAT rule, when a packet matching the rule comes in it is sent to the specified host, obviously this is done by changing the destination field to be the system 'behind' the firewall.  It was however my understanding--and what I've seen in practice--that the source field would not be changed.  So in other words the source of the packet would still be the host out on the internet that actually sent the original packet.  However I have made a set of DNAT rules that I couldn't get to work. So a setup a packet sniffer at several points.  Here is what I noticed and has me confused.


The inside computer (A) sends out a UDP packet to the internet connected computer (B), of course this packet goes through firewall (FW).

The packet goes out as expect srcA dstB
But the weird part is the response comes back in srcFW dst(A)   Where I would like it would be src(B) dst(A)!!!

I think this is screwing up the communications.  Can anyone help me understand what is happening?

-    Craig

**********New Info**************

I've been continueing to troubleshoot this thing and have found the following information that may help someone.

Here is what I see in the middle of a connection attempt from conntrack:
 udp      17 27 src=192.168.25.11 dst=66.250.84.85 sport=137 dport=137 [UNREPLIED] 
  src=66.*.*.* dst=24.154.175.175 sport=137 dport=137 use=1

 udp      17 29 src=66.*.*.* dst=24.154.175.175 sport=5199 dport=5198 [UNREPLIED]
  src=192.168.25.11 dst=192.168.25.1 sport=5198 dport=5199 use=1

 udp      17 24 src=66.*.*.* dst=24.154.175.175 sport=5199 dport=5199 [UNREPLIED] 
  src=192.168.25.11 dst=192.168.25.1 sport=5199 dport=5199 use=1

Note the first one appears to be a attempt to resolve the system name via NetBlewy.  The next two are the actual connections coming in.  Note they appear to *want* the outbound packets to be addressed to 25.1 (The IPtables box).  This would mean my understanding above is wrong.  Here is a trace from the iptables box:

16:21:28.884621 66.*.*.*.5199 > 24.154.175.175.5198:  udp 144
16:21:28.884735 192.168.25.1.5199 > 192.168.25.11.5198:  udp 144
16:21:28.963044 66.*.*.* .5199 > 24.154.175.175.5198:  udp 144
16:21:28.963167 192.168.25.1.5199 > 192.168.25.11.5198:  udp 144
16:21:29.041030 66.*.*.* .5199 > 24.154.175.175.5198:  udp 144
16:21:29.041178 192.168.25.1.5199 > 192.168.25.11.5198:  udp 144

As you can see, as the live connection comes in, it then goes out to the 'inside' system.  Note also that the source does infact change to the iptables system from the outside system.

Here is a trace from the inside system:

21:04:14.737871 IP 192.168.25.1.5199 > 192.168.25.11.5198: udp 144
21:04:14.814408 IP 192.168.25.1.5199 > 192.168.25.11.5198: udp 144
21:04:14.893168 IP 192.168.25.1.5199 > 192.168.25.11.5198: udp 144
21:04:14.954960 IP 192.168.25.11.3903 > 66.*.*.* .5199: udp 96

Now the problem is, that since this is UDP I don't know if the last packet is an ack type packet or a retry on the initial setup (i.e. it doesn't 'know' that 192.168.25.1 is answer its 66.xx.xx.xx request?)

I'm totaly stuck.  Can anyone at least turn me in the direction of some more troubleshooting tools I can use.  Because it is UDP i'm having a lot of trouble, because I can't figure out what was recieved and what wasn't (no ack).

    - Craig




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.467 / Virus Database: 266 - Release Date: 4/1/2003

[-- Attachment #2: Type: text/html, Size: 6270 bytes --]

Re: UDP DNAT help

[Joel Newkirk]

On Monday 07 April 2003 10:31 pm, Craig Packard wrote:
> **********Original Post***********
>
> From what I understand if I setup a DNAT rule, when a packet matching
> the rule comes in it is sent to the specified host, obviously this is
> done by changing the destination field to be the system 'behind' the
> firewall.  It was however my understanding--and what I've seen in
> practice--that the source field would not be changed.  So in other
> words the source of the packet would still be the host out on the
> internet that actually sent the original packet.  However I have made
> a set of DNAT rules that I couldn't get to work. So a setup a packet
> sniffer at several points.  Here is what I noticed and has me
> confused.
>
>
> The inside computer (A) sends out a UDP packet to the internet
> connected computer (B), of course this packet goes through firewall
> (FW).
>
> The packet goes out as expect srcA dstB
> But the weird part is the response comes back in srcFW dst(A)   Where
> I would like it would be src(B) dst(A)!!!
>
> I think this is screwing up the communications.  Can anyone help me
> understand what is happening?
>
> -    Craig

Sounds like a SNAT rule that isn't tied down to just the external 
interface.  Including packet traces and sniffs is potentially useful, 
but more useful would be any SNAT and DNAT rules themselves.

j

Re: UDP DNAT help

[Craig Packard]

> 
> Sounds like a SNAT rule that isn't tied down to just the external 
> interface.  Including packet traces and sniffs is potentially useful, 
> but more useful would be any SNAT and DNAT rules themselves.
> 

I've already posted my PREROUTING chain to the list.  And in the same 
message you replied to was several packet captures further down the 
message.  There is no SNATing anywhere--on any interface.  I would be 
thankful for any help or info on more places to look to troubleshoot.

	- Craig

Re: UDP DNAT help

[Joel Newkirk]

On Tuesday 11 March 2003 06:44 am, Craig Packard wrote:
> > Sounds like a SNAT rule that isn't tied down to just the external
> > interface.  Including packet traces and sniffs is potentially
> > useful, but more useful would be any SNAT and DNAT rules themselves.
>
> I've already posted my PREROUTING chain to the list.  And in the same

I've not been able to find it.  I found a request for it on Friday from 
Ralf Spenneberg but if you posted it to the list I didn't receive that 
post.  (not hard to believe - I seem to get a good percentage of this 
list several days late - not just messages awaiting moderator approval)

> message you replied to was several packet captures further down the
> message.  There is no SNATing anywhere--on any interface.  I would be
> thankful for any help or info on more places to look to troubleshoot.

Sorry, I was aware of the captures in that message, but snipped them from 
my reply for brevity.

My suggestion for further troubleshooting at this point would be to set 
up a few LOG rules temporarily to try to track the progress of the 
packets through netfilter.

iptables -t nat -I PREROUTING 1 -p udp -s 192.168.25.11 -j LOG 
--log-prefix "NatPreS:"
iptables -I FORWARD 1 -p udp -s 192.168.25.11 -j LOG --log-prefix "FwdS:"
iptables -t nat -I POSTROUTING 1 -p udp -d 192.168.25.11 -j LOG 
--log-prefix NatPostD:"

etc.  If you have loaded (or can load) mangle table, put the log rules in 
mangle PREROUTING and POSTROUTING instead of nat.  Log both directions, 
matching the specific source/dest port if possible, else matching 
source/dest IP of both the local and remote boxes.

Make a few connection attempts (then remove the log rules) and then 
examine the log entries to see what IPs appear where.  This may help 
narrow down what packets are being modified at which stage.  By 
examining packet IDs, src/dest IPs, and the log-prefix to identify which 
chain logged the entry, you should get a fairly good picture of what is 
taking place within netfilter regarding these connections.  

> 	- Craig

j