|
**********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="" dst=66.250.84.85 sport=137 dport=137 [UNREPLIED]
src="" dst=24.154.175.175 sport=137 dport=137 use=1 udp 17 29
src="" dst=24.154.175.175 sport=5199 dport=5198
[UNREPLIED]
src="" dst=192.168.25.1 sport=5198 dport=5199 use=1 udp 17 24
src="" dst=24.154.175.175 sport=5199 dport=5199 [UNREPLIED]
src="" 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 |
