* HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
@ 2005-03-23 17:08 ` Trevor Paskett
0 siblings, 0 replies; 13+ messages in thread
From: Trevor Paskett @ 2005-03-23 17:08 UTC (permalink / raw)
To: Trevor Paskett, netfilter; +Cc: netfilter-devel
So no takers on this? Nobody has the same issue, or can re-create it? We
are desperate for a solution to this, and are willing to pay for a fix
if necessary. Please help!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
-----Original Message-----
From: Trevor Paskett
Sent: Friday, March 18, 2005 3:42 PM
To: netfilter@lists.netfilter.org
Cc: netfilter-devel@lists.netfilter.org
Subject: RE: Transparent Proxy using bridging 2.6.9 and REDIRECT
ondifferent subnet
I have more information o this problem. I have also cc'd the development
list as I think this could be a bug, but it is probably something I'm
doing wrong :)
With the test machine on another subnet that the REDIRECT linux box,
everything works up until the return packet to the client with the HTTP
body. Running ethereal shows that the test workstation gets a packet,
but the src port is 1 and not 80 as it should be.
Adding some prink's into ipt_REDIRECT shows that when it goes through
that module the port numbers are correct. I turned on debugging in
ipt_nat_core.c and get this output:
Mar 18 16:29:52 debian kernel: Found best for tuple c02f1c98: 6
192.168.255.152:4012 -> 192.168.12.165:80
Mar 18 16:29:52 debian kernel: Mangling f45a96a0: DST to 192.168.12.165
8888
Mar 18 16:29:52 debian kernel: Mangling f45c0660: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Mangling f45b4680: DST to 192.168.12.165
8888
Mar 18 16:29:52 debian kernel: Found best for tuple ed1dbbb4: 6
127.0.0.1:33186 -> 127.0.0.1:3128
Mar 18 16:29:52 debian kernel: Mangling f45c0de0: DST to 192.168.12.165
8888
Mar 18 16:29:52 debian kernel: Mangling f45b4680: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Found best for tuple ed1dbcf0: 6
192.168.255.3:80 -> 192.168.255.152:4012
Mar 18 16:29:52 debian kernel: Trying implicit mapping
Mar 18 16:29:52 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3 1
Mar 18 16:29:52 debian kernel: Found best for tuple ed1db9a4: 6
192.168.255.3:1 -> 192.168.255.152:4012
Mar 18 16:29:52 debian kernel: Found best for tuple f426f898: 6
192.168.12.165:33187 -> 192.168.255.3:80
Mar 18 16:29:52 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Mangling f45c0060: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Mangling f4132cc0: SRC to 192.168.255.3 1
Mar 18 16:29:52 debian kernel: Mangling f45b4c80: SRC to 192.168.255.3 1
Mar 18 16:29:55 debian kernel: Mangling f4782aa0: DST to 192.168.12.165
8888
Mar 18 16:29:55 debian kernel: Mangling f4782aa0: SRC to 192.168.255.3
80
Mar 18 16:29:55 debian kernel: Mangling f4512dc0: SRC to 192.168.255.3 1
Mar 18 16:29:55 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3
80
Mar 18 16:29:55 debian kernel: Mangling f4782da0: SRC to 192.168.255.3 1
Mar 18 16:29:58 debian kernel: Found best for tuple e4611bb4: 6
127.0.0.1:33188 -> 127.0.0.1:2003
Mar 18 16:30:01 debian kernel: Mangling f45a99a0: DST to 192.168.12.165
8888
Mar 18 16:30:01 debian kernel: Mangling f45a99a0: SRC to 192.168.255.3
80
Mar 18 16:30:01 debian kernel: Mangling f45a95e0: SRC to 192.168.255.3 1
Mar 18 16:30:01 debian kernel: Mangling f45a95e0: SRC to 192.168.255.3
80
Mar 18 16:30:01 debian kernel: Mangling f4512940: SRC to 192.168.255.3 1
Mar 18 16:30:04 debian kernel: Found best for tuple e4b9fbb4: 6
127.0.0.1:33189 -> 127.0.0.1:2003
It looks like right after 'Trying implicit mapping' the SRC port gets
changed to 1, when it should be 80. I've poked around ip_nat_core.c but
have never looked in there before and can't find the problem. Am I
looking to deep? Is it something more simple that this? I tried this
with 2.6.11.4 and had the same result. Thanks!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
-----Original Message-----
From: Trevor Paskett
Sent: Friday, March 18, 2005 10:41 AM
To: netfilter@lists.netfilter.org
Subject: Transparent Proxy using bridging 2.6.9 and REDIRECT on
differentsubnet
I have the following setup
Test Machine ---> Linux 2.6.9 ---> Internet Router (Doing NAT)
192.168.255.152 192.168.255.165 192.168.255.1/24
192.168.12.1/24
I have blacked out all my iptables and ebtables all default ACCEPT
policy.
The Linux 2.6.9 is bridging. I use the following rule to redirect port
80 traffic to Squid on the Linux 2.6.9 box:
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT
--to-port 3128
This works just like it should. No problem. The problems comes in this
setup:
Test Machine ---> Linux 2.6.9 ---> Internet Router (Doing NAT)
192.168.255.152 192.168.12.165 192.168.255.1
192.168.12.1
When the Linux box is on a different subnet that the test machine the
request will get to Squid, the rules get a packet count I see squid get
the request. Then squid try to send the request back to the client and
it hangs up. The browser just spins. The test machine and the Linux
2.6.9 can both ping each other so I know connectivity is ok.
Now if I bring up an alias br0:0 192.168.255.165 in the above setup,
then everything works again. So does the br0 have to have an ip on the
same subnet for REDIRECT to work? I have also tried adding ebtables
rules like:
ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 \
--ip-destination-port 80 -j redirect --redirect-target ACCEPT
Makes no difference. I have also tried some more complex variations
like:
iptables -t nat -A PREROUTING -p tcp -m physdev --physdev-in eth1
--dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -p tcp -i br0 --dport -j DNAT --to
i92.168.12.165:3128
All see to work the same. Broken :) I have messed around with settings
on /proc/sys/net to no avail.
I'm using iptables v1.2.9 and Linux 2.6.9. Debian Woody. Thanks!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
^ permalink raw reply [flat|nested] 13+ messages in thread
* HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
@ 2005-03-23 17:08 ` Trevor Paskett
0 siblings, 0 replies; 13+ messages in thread
From: Trevor Paskett @ 2005-03-23 17:08 UTC (permalink / raw)
To: Trevor Paskett, netfilter; +Cc: netfilter-devel
So no takers on this? Nobody has the same issue, or can re-create it? We
are desperate for a solution to this, and are willing to pay for a fix
if necessary. Please help!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
-----Original Message-----
From: Trevor Paskett
Sent: Friday, March 18, 2005 3:42 PM
To: netfilter@lists.netfilter.org
Cc: netfilter-devel@lists.netfilter.org
Subject: RE: Transparent Proxy using bridging 2.6.9 and REDIRECT
ondifferent subnet
I have more information o this problem. I have also cc'd the development
list as I think this could be a bug, but it is probably something I'm
doing wrong :)
With the test machine on another subnet that the REDIRECT linux box,
everything works up until the return packet to the client with the HTTP
body. Running ethereal shows that the test workstation gets a packet,
but the src port is 1 and not 80 as it should be.
Adding some prink's into ipt_REDIRECT shows that when it goes through
that module the port numbers are correct. I turned on debugging in
ipt_nat_core.c and get this output:
Mar 18 16:29:52 debian kernel: Found best for tuple c02f1c98: 6
192.168.255.152:4012 -> 192.168.12.165:80
Mar 18 16:29:52 debian kernel: Mangling f45a96a0: DST to 192.168.12.165
8888
Mar 18 16:29:52 debian kernel: Mangling f45c0660: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Mangling f45b4680: DST to 192.168.12.165
8888
Mar 18 16:29:52 debian kernel: Found best for tuple ed1dbbb4: 6
127.0.0.1:33186 -> 127.0.0.1:3128
Mar 18 16:29:52 debian kernel: Mangling f45c0de0: DST to 192.168.12.165
8888
Mar 18 16:29:52 debian kernel: Mangling f45b4680: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Found best for tuple ed1dbcf0: 6
192.168.255.3:80 -> 192.168.255.152:4012
Mar 18 16:29:52 debian kernel: Trying implicit mapping
Mar 18 16:29:52 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3 1
Mar 18 16:29:52 debian kernel: Found best for tuple ed1db9a4: 6
192.168.255.3:1 -> 192.168.255.152:4012
Mar 18 16:29:52 debian kernel: Found best for tuple f426f898: 6
192.168.12.165:33187 -> 192.168.255.3:80
Mar 18 16:29:52 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Mangling f45c0060: SRC to 192.168.255.3
80
Mar 18 16:29:52 debian kernel: Mangling f4132cc0: SRC to 192.168.255.3 1
Mar 18 16:29:52 debian kernel: Mangling f45b4c80: SRC to 192.168.255.3 1
Mar 18 16:29:55 debian kernel: Mangling f4782aa0: DST to 192.168.12.165
8888
Mar 18 16:29:55 debian kernel: Mangling f4782aa0: SRC to 192.168.255.3
80
Mar 18 16:29:55 debian kernel: Mangling f4512dc0: SRC to 192.168.255.3 1
Mar 18 16:29:55 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3
80
Mar 18 16:29:55 debian kernel: Mangling f4782da0: SRC to 192.168.255.3 1
Mar 18 16:29:58 debian kernel: Found best for tuple e4611bb4: 6
127.0.0.1:33188 -> 127.0.0.1:2003
Mar 18 16:30:01 debian kernel: Mangling f45a99a0: DST to 192.168.12.165
8888
Mar 18 16:30:01 debian kernel: Mangling f45a99a0: SRC to 192.168.255.3
80
Mar 18 16:30:01 debian kernel: Mangling f45a95e0: SRC to 192.168.255.3 1
Mar 18 16:30:01 debian kernel: Mangling f45a95e0: SRC to 192.168.255.3
80
Mar 18 16:30:01 debian kernel: Mangling f4512940: SRC to 192.168.255.3 1
Mar 18 16:30:04 debian kernel: Found best for tuple e4b9fbb4: 6
127.0.0.1:33189 -> 127.0.0.1:2003
It looks like right after 'Trying implicit mapping' the SRC port gets
changed to 1, when it should be 80. I've poked around ip_nat_core.c but
have never looked in there before and can't find the problem. Am I
looking to deep? Is it something more simple that this? I tried this
with 2.6.11.4 and had the same result. Thanks!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
-----Original Message-----
From: Trevor Paskett
Sent: Friday, March 18, 2005 10:41 AM
To: netfilter@lists.netfilter.org
Subject: Transparent Proxy using bridging 2.6.9 and REDIRECT on
differentsubnet
I have the following setup
Test Machine ---> Linux 2.6.9 ---> Internet Router (Doing NAT)
192.168.255.152 192.168.255.165 192.168.255.1/24
192.168.12.1/24
I have blacked out all my iptables and ebtables all default ACCEPT
policy.
The Linux 2.6.9 is bridging. I use the following rule to redirect port
80 traffic to Squid on the Linux 2.6.9 box:
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT
--to-port 3128
This works just like it should. No problem. The problems comes in this
setup:
Test Machine ---> Linux 2.6.9 ---> Internet Router (Doing NAT)
192.168.255.152 192.168.12.165 192.168.255.1
192.168.12.1
When the Linux box is on a different subnet that the test machine the
request will get to Squid, the rules get a packet count I see squid get
the request. Then squid try to send the request back to the client and
it hangs up. The browser just spins. The test machine and the Linux
2.6.9 can both ping each other so I know connectivity is ok.
Now if I bring up an alias br0:0 192.168.255.165 in the above setup,
then everything works again. So does the br0 have to have an ip on the
same subnet for REDIRECT to work? I have also tried adding ebtables
rules like:
ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 \
--ip-destination-port 80 -j redirect --redirect-target ACCEPT
Makes no difference. I have also tried some more complex variations
like:
iptables -t nat -A PREROUTING -p tcp -m physdev --physdev-in eth1
--dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -p tcp -i br0 --dport -j DNAT --to
i92.168.12.165:3128
All see to work the same. Broken :) I have messed around with settings
on /proc/sys/net to no avail.
I'm using iptables v1.2.9 and Linux 2.6.9. Debian Woody. Thanks!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
@ 2005-03-23 19:18 Trevor Paskett
0 siblings, 0 replies; 13+ messages in thread
From: Trevor Paskett @ 2005-03-23 19:18 UTC (permalink / raw)
To: Nguyen Dinh Nam; +Cc: netfilter-devel, netfilter
Yes it is on. It works great when the test machine is on the same subnet
as the Linux box. When it is on a different subnet, then the clients
gets packets back like it should but the port number on the packet is 1
instead of 80 like it is when they are on the same subnet.
Then if I bring up an alias br0:0 with an IP on that subnet everything
works great again. Thanks!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
-----Original Message-----
From: Nguyen Dinh Nam [mailto:64vn@cardvn.net]
Sent: Wednesday, March 23, 2005 11:01 AM
To: Trevor Paskett
Subject: Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT
on different subnet
on the Linux machine (the one with squid), is
/proc/sys/net/ipv4/ip_forward turned on?
Trevor Paskett wrote:
>So no takers on this? Nobody has the same issue, or can re-create it?
We
>are desperate for a solution to this, and are willing to pay for a fix
>if necessary. Please help!!
>
>Trevor Paskett
>Cymphonix Programmer - CCNA, CWNA
>P: 801-938-1500 F: 801-938-1501
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
2005-03-23 17:08 ` Trevor Paskett
(?)
@ 2005-03-23 19:24 ` Grant Taylor
2005-03-23 19:42 ` Jason Opperisano
-1 siblings, 1 reply; 13+ messages in thread
From: Grant Taylor @ 2005-03-23 19:24 UTC (permalink / raw)
To: Trevor Paskett; +Cc: netfilter
I'll take a stab at this. I too saw the original post but did not reply as I did not have any good answer at the time and still do not. But this would be my thought process on this matter.
Per Trevor's original post the problem arises when the Linux 2.6.9 Squid box redirects traffic back to it's self when it is on a different subnet. Yet the "Test Machine" can ping the "Linux 2.6.9" system. To what address are you trying to ping the "Linux 2.6.9" on 192.168.12.165 or 192.168.255.165? The address that you are pinging will make a difference as the packets travel through the network. If you try to ping the 192.168.12.165 address the ping packets will travel from the "Test Machine" through the "Linux 2.6.9" system's br0 interface on it's way in to the router via the 192.168.255.1 address and out of the router via the 192.168.12.1 address to the "Linux 2.6.9" system's 192.168.12.165 address. Now if you consider that packet path and change the packet to be a port 80 TCP connection the packet will follow this path. Traffic leaving the "Test Machine" through the "Linux 2.6.
9" system's br0 interface where it will be intercepted and redirected to port 3128 of whi
ch address? I'll assume that it will be redirected to 192.168.12.165:3128 thus going directly in to Squid on the "Linux 2.6.9" system. The problem will be the return traffic from the Squid system back to the "Test Machine" in such that the source address on the packet will probably be the 192.168.12.165 address of the "Linux 2.6.9" system not what the TCP stack on the "Test Machine" is expecting.
I'm assuming that you have a valid reason for putting Squid on a different subnet than the client machines in question. If I were trying to do this from the ground up I would make sure of a few things:
1) REDIRECT or DNAT traffic coming from the client machine to proxy with a known address.
2) SNAT traffic coming from the proxy with a known address back to an address the client machines are expecting. I'm not sure as of how to do this as the source address that they are expecting will be different depending on where they are trying to connect to. Seeing as how Squid can correctly transparent proxy traffic when it is on the correct subnet I'm going to assume that it knows how to handle this issue.
As there are a LOT of things going on in this mix I'm sort of at a loss as to what to do beyond this point with out more information as to what you are doing and why you might be doing this on a technical level, I don't care about politics. I'm willing to try to help in any way that I can but I need more data to work with on this and more time to think about it to see if I can come up with a solution.
Grant. . . .
Trevor Paskett wrote:
> So no takers on this? Nobody has the same issue, or can re-create it? We
> are desperate for a solution to this, and are willing to pay for a fix
> if necessary. Please help!!
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
>
>
> -----Original Message-----
> From: Trevor Paskett
> Sent: Friday, March 18, 2005 3:42 PM
> To: netfilter@lists.netfilter.org
> Cc: netfilter-devel@lists.netfilter.org
> Subject: RE: Transparent Proxy using bridging 2.6.9 and REDIRECT
> ondifferent subnet
>
> I have more information o this problem. I have also cc'd the development
> list as I think this could be a bug, but it is probably something I'm
> doing wrong :)
>
> With the test machine on another subnet that the REDIRECT linux box,
> everything works up until the return packet to the client with the HTTP
> body. Running ethereal shows that the test workstation gets a packet,
> but the src port is 1 and not 80 as it should be.
>
> Adding some prink's into ipt_REDIRECT shows that when it goes through
> that module the port numbers are correct. I turned on debugging in
> ipt_nat_core.c and get this output:
>
> Mar 18 16:29:52 debian kernel: Found best for tuple c02f1c98: 6
> 192.168.255.152:4012 -> 192.168.12.165:80
> Mar 18 16:29:52 debian kernel: Mangling f45a96a0: DST to 192.168.12.165
> 8888
> Mar 18 16:29:52 debian kernel: Mangling f45c0660: SRC to 192.168.255.3
> 80
> Mar 18 16:29:52 debian kernel: Mangling f45b4680: DST to 192.168.12.165
> 8888
> Mar 18 16:29:52 debian kernel: Found best for tuple ed1dbbb4: 6
> 127.0.0.1:33186 -> 127.0.0.1:3128
> Mar 18 16:29:52 debian kernel: Mangling f45c0de0: DST to 192.168.12.165
> 8888
> Mar 18 16:29:52 debian kernel: Mangling f45b4680: SRC to 192.168.255.3
> 80
> Mar 18 16:29:52 debian kernel: Found best for tuple ed1dbcf0: 6
> 192.168.255.3:80 -> 192.168.255.152:4012
> Mar 18 16:29:52 debian kernel: Trying implicit mapping
> Mar 18 16:29:52 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3 1
> Mar 18 16:29:52 debian kernel: Found best for tuple ed1db9a4: 6
> 192.168.255.3:1 -> 192.168.255.152:4012
> Mar 18 16:29:52 debian kernel: Found best for tuple f426f898: 6
> 192.168.12.165:33187 -> 192.168.255.3:80
> Mar 18 16:29:52 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3
> 80
> Mar 18 16:29:52 debian kernel: Mangling f45c0060: SRC to 192.168.255.3
> 80
> Mar 18 16:29:52 debian kernel: Mangling f4132cc0: SRC to 192.168.255.3 1
> Mar 18 16:29:52 debian kernel: Mangling f45b4c80: SRC to 192.168.255.3 1
> Mar 18 16:29:55 debian kernel: Mangling f4782aa0: DST to 192.168.12.165
> 8888
> Mar 18 16:29:55 debian kernel: Mangling f4782aa0: SRC to 192.168.255.3
> 80
> Mar 18 16:29:55 debian kernel: Mangling f4512dc0: SRC to 192.168.255.3 1
> Mar 18 16:29:55 debian kernel: Mangling f45c08a0: SRC to 192.168.255.3
> 80
> Mar 18 16:29:55 debian kernel: Mangling f4782da0: SRC to 192.168.255.3 1
> Mar 18 16:29:58 debian kernel: Found best for tuple e4611bb4: 6
> 127.0.0.1:33188 -> 127.0.0.1:2003
> Mar 18 16:30:01 debian kernel: Mangling f45a99a0: DST to 192.168.12.165
> 8888
> Mar 18 16:30:01 debian kernel: Mangling f45a99a0: SRC to 192.168.255.3
> 80
> Mar 18 16:30:01 debian kernel: Mangling f45a95e0: SRC to 192.168.255.3 1
> Mar 18 16:30:01 debian kernel: Mangling f45a95e0: SRC to 192.168.255.3
> 80
> Mar 18 16:30:01 debian kernel: Mangling f4512940: SRC to 192.168.255.3 1
> Mar 18 16:30:04 debian kernel: Found best for tuple e4b9fbb4: 6
> 127.0.0.1:33189 -> 127.0.0.1:2003
>
> It looks like right after 'Trying implicit mapping' the SRC port gets
> changed to 1, when it should be 80. I've poked around ip_nat_core.c but
> have never looked in there before and can't find the problem. Am I
> looking to deep? Is it something more simple that this? I tried this
> with 2.6.11.4 and had the same result. Thanks!!
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
>
>
> -----Original Message-----
> From: Trevor Paskett
> Sent: Friday, March 18, 2005 10:41 AM
> To: netfilter@lists.netfilter.org
> Subject: Transparent Proxy using bridging 2.6.9 and REDIRECT on
> differentsubnet
>
> I have the following setup
>
> Test Machine ---> Linux 2.6.9 ---> Internet Router (Doing NAT)
> 192.168.255.152 192.168.255.165 192.168.255.1/24
> 192.168.12.1/24
>
> I have blacked out all my iptables and ebtables all default ACCEPT
> policy.
>
> The Linux 2.6.9 is bridging. I use the following rule to redirect port
> 80 traffic to Squid on the Linux 2.6.9 box:
>
> iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT
> --to-port 3128
>
> This works just like it should. No problem. The problems comes in this
> setup:
>
> Test Machine ---> Linux 2.6.9 ---> Internet Router (Doing NAT)
> 192.168.255.152 192.168.12.165 192.168.255.1
> 192.168.12.1
>
> When the Linux box is on a different subnet that the test machine the
> request will get to Squid, the rules get a packet count I see squid get
> the request. Then squid try to send the request back to the client and
> it hangs up. The browser just spins. The test machine and the Linux
> 2.6.9 can both ping each other so I know connectivity is ok.
>
> Now if I bring up an alias br0:0 192.168.255.165 in the above setup,
> then everything works again. So does the br0 have to have an ip on the
> same subnet for REDIRECT to work? I have also tried adding ebtables
> rules like:
>
> ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 \
> --ip-destination-port 80 -j redirect --redirect-target ACCEPT
>
> Makes no difference. I have also tried some more complex variations
> like:
>
> iptables -t nat -A PREROUTING -p tcp -m physdev --physdev-in eth1
> --dport 80 -j REDIRECT --to-port 3128
> iptables -t nat -A PREROUTING -p tcp -i br0 --dport -j DNAT --to
> i92.168.12.165:3128
>
> All see to work the same. Broken :) I have messed around with settings
> on /proc/sys/net to no avail.
>
> I'm using iptables v1.2.9 and Linux 2.6.9. Debian Woody. Thanks!!
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
2005-03-23 19:24 ` Grant Taylor
@ 2005-03-23 19:42 ` Jason Opperisano
0 siblings, 0 replies; 13+ messages in thread
From: Jason Opperisano @ 2005-03-23 19:42 UTC (permalink / raw)
To: netfilter
On Wed, Mar 23, 2005 at 01:24:20PM -0600, Grant Taylor wrote:
> 1) REDIRECT or DNAT traffic coming from the client machine to proxy with a
> known address.
> 2) SNAT traffic coming from the proxy with a known address back to an
> address the client machines are expecting. I'm not sure as of how to do
> this as the source address that they are expecting will be different
> depending on where they are trying to connect to. Seeing as how Squid can
> correctly transparent proxy traffic when it is on the correct subnet I'm
> going to assume that it knows how to handle this issue.
i didn't read the original post (or re-posts thereafter, as i have
nothing of value to add to a bridging question), but i can add this to #2
there...in the case of REDIRECT--the client is expecting a response from
the target web server--so a SNAT doesn't make sense in that scenario,
as it would be pretty much guaranteed to break the communication.
REDIRECT is a whole different beast from DNAT.
-j
--
"Facts are meaningless. You could use facts to prove anything that's
even remotely true!"
--The Simpsons
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
[not found] <2F413D5F33545D4A8465BBEE900238CC3FA777@cymmail.cymphonix.com>
@ 2005-03-23 23:50 ` Grant Taylor
2005-03-24 0:35 ` Grant Taylor
` (3 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Grant Taylor @ 2005-03-23 23:50 UTC (permalink / raw)
To: Trevor Paskett; +Cc: coreteam, netfilter
Well as fate would have it, I did apparently have a need for something like this over the horizon. What am I talking about? My boss came to me today and asked me to set up something very similar to what you are doing and I ran in to the same problem that you are. Well sort of that is. As I had been thinking about a solution for your problem I tried what I was going to email you about this evening and it seems to be working for me so give it a shot and see what it does for you. Below is a description of my scenario.
We have had an employ going to web sites that we have deemed inappropriate and thus want banned. The obvious solution is to put an ACL in our Squid proxy. The problem is that I wanted to deny (transparent proxy) any one who tried to bypass the proxy. The typical transparent proxying options that are out there assume that you will just REDIRECT to Squid on the same box. This is great save for the fact that Squid is not running on our firewall as it is running on an internal system thus REDIRECT will NOT work. So I had to come up with a slightly different solution and it *may* work for you as well.
Here is my network layout:
Clients on internal LAN <-> Router <-> INet
Squid on internal LAN
My internal network is a 172.30.0.0/24 (eth1) network and all client and server (Squid) systems are on it. I access the internet on eth0.
Below are the pertinent iptables lines for this problem:
LAN="eth1"
INet="eth0"
SyslogPrefix="Proxy_Bypas_Attempt"
Subnet="172.30.0.0/24"
RouterIP="172.30.0.249"
SquidProxyIP="172.30.0.246"
SquidProxyPort="3128"
iptables -t nat -A PREROUTING -i ${LAN} -s ! ${SquidProxyIP} -p tcp --dport 80 -j LOG --log-prefix ${SyslogPrefix}
iptables -t nat -A PREROUTING -i ${LAN} -s ! ${SquidProxyIP} -p tcp --dport 80 -j DNAT --to-destination ${SquidProxyIP}:${SquidProxyPort}
iptables -t nat -A POSTROUTING -o ${LAN} -s ${Subnet} -d ${SquidProxyIP} -p tcp --dport ${SquidProxyPort} -j SNAT --to-source ${RouterIP}:${SquidProxyPort}
What this does is to take any traffic that would pass through the router that is destined to TCP port 80 and DNATs it to the Squid Proxy on the port that it is listening on. As the traffic is going out of the router on it's way to the proxy it gets SNATed to appear as if it is from the router it's self so the traffic will come back to the router where it will be unSNATed and then unDNATed back to the client systems that made the request in the first place. The problem that was seen before hand of just DNATing the traffic to the Squid Proxy box where Squid would see traffic coming from the client systems and just reply is avoided by SNATing the traffic to appear as if it is coming from the router. The LOG target line is just so you have the internal IP and MAC address of the system that is attempting to bypass the proxy thus giving you information to go on a (wo)man hunt.
Give this a try and see if you can make it any further with it. I don't know if it will be directly applicable in your situation or not. I'll still do some more chewing on your scenario and see if I think this will work for you or not. I just know that I was handed a problem that was very similar to yours this afternoon and only because I've been thinking about your scenario did I have a solution to test as quickly as I did. So in a way I suppose that I should say thank you, so "Thank you!", as you gave me a reason to preemptively solve my problem too. :) I'll let you know what I come up with regarding bridging and firewalling traffic.
Grant. . . .
Trevor Paskett wrote:
> Thanks for your reply. Our product is a Linux based product that uses
> netfilter. We have Squid and a filtering engine on our box. We are
> strong supporters of netfilter. Our customers have many subnets behind
> our box because of where it is placed in their network. Bringing up
> alias's on br0 for each of their subnets that are not even on that
> broadcast domain is a big band aid :). I think this is somehow a bug in
> ip_nat_core.c and will investigate that further and have cc'd
> coreteam@netfilter.org and hopefully that will get to Rusty who wrote
> it.
>
> As for the SNAT I think Jason Opperisano's response is correct.
> Everything works great, except somewhere in ip_nat_core.c the src port
> is getting changed to 1 from 80. I have attached an ethereal dump to
> show this happening and a dump when it does what it is supposed to.
> Everything between the 2 is the same, except after I captured the
> no_work.cap, I did
>
> ifconfig br0:0 192.168.255.165
>
> So it had an IP on the test machine's subnet. Of course it worked fine
> and that capture is work.cap
>
> Thanks for all your help.
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
[not found] <2F413D5F33545D4A8465BBEE900238CC3FA777@cymmail.cymphonix.com>
2005-03-23 23:50 ` Grant Taylor
@ 2005-03-24 0:35 ` Grant Taylor
2005-03-24 6:25 ` Grant Taylor
` (2 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Grant Taylor @ 2005-03-24 0:35 UTC (permalink / raw)
To: Trevor Paskett; +Cc: coreteam, netfilter
One thing that I forgot to mention is that if you are DROPing FORWARD traffic in your filter / FORWARD table you will need to ACCEPT traffic that come sin your LAN interface and back out your LAN interface.
iptables -t filter -A FORWARD -i ${LAN} -o ${LAN} -j ACCEPT
You could possibly put a -s and -d match in place to tighter constraints on what is forwarded around the LAN.
Grant. . . .
Trevor Paskett wrote:
> Thanks for your reply. Our product is a Linux based product that uses
> netfilter. We have Squid and a filtering engine on our box. We are
> strong supporters of netfilter. Our customers have many subnets behind
> our box because of where it is placed in their network. Bringing up
> alias's on br0 for each of their subnets that are not even on that
> broadcast domain is a big band aid :). I think this is somehow a bug in
> ip_nat_core.c and will investigate that further and have cc'd
> coreteam@netfilter.org and hopefully that will get to Rusty who wrote
> it.
>
> As for the SNAT I think Jason Opperisano's response is correct.
> Everything works great, except somewhere in ip_nat_core.c the src port
> is getting changed to 1 from 80. I have attached an ethereal dump to
> show this happening and a dump when it does what it is supposed to.
> Everything between the 2 is the same, except after I captured the
> no_work.cap, I did
>
> ifconfig br0:0 192.168.255.165
>
> So it had an IP on the test machine's subnet. Of course it worked fine
> and that capture is work.cap
>
> Thanks for all your help.
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
[not found] <2F413D5F33545D4A8465BBEE900238CC3FA777@cymmail.cymphonix.com>
2005-03-23 23:50 ` Grant Taylor
2005-03-24 0:35 ` Grant Taylor
@ 2005-03-24 6:25 ` Grant Taylor
2005-03-24 8:50 ` Grant Taylor
2005-03-24 21:09 ` Grant Taylor
4 siblings, 0 replies; 13+ messages in thread
From: Grant Taylor @ 2005-03-24 6:25 UTC (permalink / raw)
To: Trevor Paskett; +Cc: coreteam, netfilter
The more that I think about this the more that I think it is possible to do, though not as you might think.
For the sake of arguing let's restate / layout the network as it will be in production:
[ Test System(s) ] <---> [Linux 2.6.9 System] <---> [ INet Router ]
(192.168.255.152) (192.168.255.1)
(192.168.12.165) (192.168.12.1 )
Again the firewall rule that you propose:
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 3128
At first glance this seems as if it would work. Indeed the traffic will make it from the "Test System(s)" to the "Linux 2.6.9 System" and in to Squid. The problem is that when the traffic comes in to "Linux 2.6.9 System" running Squid it will be seen as from a "Test System's" IP address of 192.168.255.152 thus when the "Linux 2.6.9 System" running Squid replies it will have to do so from it's NIC on 192.168.12.165 to 192.168.255.152. (We will assume that the "Linux 2.6.9 System" has a route to the 192.168.255.x/24 network via the "INet Router".) Seeing as how the "Test System" would have sent the traffic out of it's NIC from 192.168.255.152 to 12.34.56.78 it would not like the response that it believes it should get appearing to come from 192.168.12.165 and thus drop the packet as part of the normal TCP/IP stack operation. Thus we have to get the traffic to enter the "Linux 2.6.9" s
ystem in such a way as it can subsequently leave it from the address that the "Test System
" is expecting a response from, i.e. 12.34.56.78. Rather than using REDIRECT I propose something more along the lines of what I had to do on my Transparent Prosy earlier today.
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:3128
iptables -t nat -A POSTROUTING -o lo -p tcp --dport 3128 -j SNAT --to-source --to-source 127.0.0.1:3128
This should allow all traffic that is passing through br0 (presumably originating from systems behind the "Linux 2.6.9 System" away from the "INet Router") to be DNATed to the localhost. The DNAT code will / should maintain the original destination IP address to unDNAT when it comes back through in reverse direction (black magic here). To alleviate the problem of Squid replying directly to the "Test System(s)" directly we need to SNAT the traffic as it is on it's way out (first step in the process to reach Squid) the lo interface. Thus Squid will see all traffic as coming from the "Linux 2.6.9 System" lo interface and reply to it there vs the "Test System(s)" directly. As such when Squid replies to the traffic it will pass back through the lo interface and be unSNATed back to the original source of the "Test System(s)" and subsequently unDNATed back to the original destination of the
original packets. Here in lies the rub, seeing as how the "Linux 2.6.9 System" does not
have a directly attached interface to the 192.168.255.x/24 subnet it will send the traffic to it's default gateway (or any gateway that is established as a route to the 192.168.255.x/24 subnet). So the "INet Router" will have to be configured to allow traffic that appears to be coming in to it from it's internal interface with a globally routeable (internet) IP and back out to the destination IP address on the same interface.
With this type of configuration the traffic will pass from the "Test System(s)" in to the "Linux 2.6.9 System" br0 interface and then be redirected, DNATed, SNATed, in to Squid on lo and then out of Squid, unSNATed, unDNATed, and then to the "INet Router", out of the "INet Router" in to the "Linux 2.6.9 System" br0 interface (with a source, not destination port of 80 (thus bypassing the rule that started this charade)), out the "Linux 2.6.9 System" br0 interface and back in to the "Test System(s)" ethernet interface appearing as if the traffic did come from the world back in. Thus your packets will have a VERY convoluted path to and from the supposed internet site. You will also have to be able to control and / or allow some VERY weird inbound IPs on the internal side of the "INet Router". Unfortunately I don't know of another way to get the "Linux 2.6.9" system to send traffic back t
o the 192.168.255.x/24 subnet. I'll keep thinking / digging on it.
Also know that this is untested as of yet so I don't know if it will work for sure or not with the Squid process on the same interface as where the SNATing is going on. I will be testing this on a system I have at my house with SSH to see if I can get this to work or not. If I am correct and this works I should be able to make it appear as if I'm SSHed in to my system from 127.0.0.1. Wish me luck!
Grant. . . .
Trevor Paskett wrote:
> Thanks for your reply. Our product is a Linux based product that uses
> netfilter. We have Squid and a filtering engine on our box. We are
> strong supporters of netfilter. Our customers have many subnets behind
> our box because of where it is placed in their network. Bringing up
> alias's on br0 for each of their subnets that are not even on that
> broadcast domain is a big band aid :). I think this is somehow a bug in
> ip_nat_core.c and will investigate that further and have cc'd
> coreteam@netfilter.org and hopefully that will get to Rusty who wrote
> it.
>
> As for the SNAT I think Jason Opperisano's response is correct.
> Everything works great, except somewhere in ip_nat_core.c the src port
> is getting changed to 1 from 80. I have attached an ethereal dump to
> show this happening and a dump when it does what it is supposed to.
> Everything between the 2 is the same, except after I captured the
> no_work.cap, I did
>
> ifconfig br0:0 192.168.255.165
>
> So it had an IP on the test machine's subnet. Of course it worked fine
> and that capture is work.cap
>
> Thanks for all your help.
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
[not found] <2F413D5F33545D4A8465BBEE900238CC3FA777@cymmail.cymphonix.com>
` (2 preceding siblings ...)
2005-03-24 6:25 ` Grant Taylor
@ 2005-03-24 8:50 ` Grant Taylor
2005-03-24 21:09 ` Grant Taylor
4 siblings, 0 replies; 13+ messages in thread
From: Grant Taylor @ 2005-03-24 8:50 UTC (permalink / raw)
To: Trevor Paskett; +Cc: coreteam, netfilter
Bad news. I'm unable to get my system here at the house to intercept traffic destined to port 22 (I chose SSH to work / test with as I don't have Squid installed on any there here at the house) and redirect it to it's self and successfully return the traffic back to my test workstation. What I was testing was a bit different than what you are asking for help on but it should still serve as a proof of concept. I was attempting to redirect traffic that was passing through my test firewall destined to port 22 to the local host port 22. Below are the rules that I tested with:
iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destination 127.0.0.1:22
iptables -t nat -A POSTROUTING -p tcp --dport 22 -j SNAT --to-source 127.0.0.1
If I just use something like the following:
iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT
I can get connected but my connections do not show up from where I would expect them to show up from, namely the firewall it's self.
Where as if I use the following rules, a slight modification of the first set just pointing to a different box, things work fine:
iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destination 172.30.254.11:22
iptables -t nat -A POSTROUTING -p tcp --dport 22 -j SNAT --to-source 172.30.254.253
Ultimately I have a feeling the problem has to do with the packets traversal of the kernel / TCP/IP stack and where we can interface / interfere with it. That being said some extremely dastardly things are probably going to need to be done to make things work the way that you want. Thus are you willing to do some nasty things as running Squid in a UML, or what about just a UML router that does nothing other than rout the packets between a couple of interfaces thus allowing you to send traffic to a different system while still being in the same box? If that was the case I think my solution where things were DNATed/SNATed to send the traffic to a foreign system and then ultimately rerouted the long way around would work, but it will be extremely nasty. It will probably work, but I don't know if you will like it. Unfortunately you are trying to do something that is EXTREMELY NOT normal
and thus are left with extremely not normal solutions.
Grant. . . .
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
@ 2005-03-24 19:04 ` Trevor Paskett
0 siblings, 0 replies; 13+ messages in thread
From: Trevor Paskett @ 2005-03-24 19:04 UTC (permalink / raw)
To: gtaylor; +Cc: coreteam, netfilter, netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Thanks for your reply. Our product is a Linux based product that uses
netfilter. We have Squid and a filtering engine on our box. We are
strong supporters of netfilter. Our customers have many subnets behind
our box because of where it is placed in their network. Bringing up
alias's on br0 for each of their subnets that are not even on that
broadcast domain is a big band aid :). I think this is somehow a bug in
ip_nat_core.c and will investigate that further and have cc'd
coreteam@netfilter.org and hopefully that will get to Rusty who wrote
it.
As for the SNAT I think Jason Opperisano's response is correct.
Everything works great, except somewhere in ip_nat_core.c the src port
is getting changed to 1 from 80. I have attached an ethereal dump to
show this happening and a dump when it does what it is supposed to.
Everything between the 2 is the same, except after I captured the
no_work.cap, I did
ifconfig br0:0 192.168.255.165
So it had an IP on the test machine's subnet. Of course it worked fine
and that capture is work.cap
Thanks for all your help.
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
[-- Attachment #2: work.cap --]
[-- Type: application/octet-stream, Size: 10181 bytes --]
No. Time Source Destination Protocol Info
1 0.000000 192.168.255.152 192.168.255.3 TCP 3380 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x9e52 (correct)
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.000194 192.168.255.3 192.168.255.152 TCP http > 3380 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 5840
Checksum: 0xed82 (correct)
Options: (8 bytes)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
3 0.000240 192.168.255.152 192.168.255.3 TCP 3380 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x3117 (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
4 0.000625 192.168.255.152 192.168.255.3 HTTP GET /test/ HTTP/1.1
Frame 4 (458 bytes on wire, 458 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 1, Ack: 1, Len: 404
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 405 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1c43 (correct)
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.001738 192.168.255.3 192.168.255.152 TCP http > 3380 [ACK] Seq=1 Ack=405 Win=6432 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 1, Ack: 405, Len: 0
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 405 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0x1663 (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
6 0.006142 192.168.255.3 192.168.255.152 HTTP HTTP/1.0 200 OK (text/html)
Frame 6 (1168 bytes on wire, 1168 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 1114
Source port: http (80)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Next sequence number: 1114 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0xc754 (correct)
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
7 0.006193 192.168.255.152 192.168.255.3 TCP 3379 > http [RST, ACK] Seq=0 Ack=1114 Win=0 Len=0
Frame 7 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 0, Ack: 1114, Len: 0
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1114 (relative ack number)
Header length: 20 bytes
Flags: 0x0014 (RST, ACK)
Window size: 0
Checksum: 0xdc3a (correct)
No. Time Source Destination Protocol Info
8 0.012826 192.168.255.3 192.168.255.152 HTTP HTTP/1.0 200 OK
Frame 8 (71 bytes on wire, 71 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 1, Ack: 405, Len: 17
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 1 (relative sequence number)
Next sequence number: 18 (relative sequence number)
Acknowledgement number: 405 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 6432
Checksum: 0x5685 (correct)
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
9 0.014988 192.168.255.3 192.168.255.152 HTTP Continuation or non-HTTP traffic (text/html)
Frame 9 (1151 bytes on wire, 1151 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 18, Ack: 405, Len: 1097
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 18 (relative sequence number)
Next sequence number: 1115 (relative sequence number)
Acknowledgement number: 405 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0x1cc4 (correct)
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
10 0.015094 192.168.255.152 192.168.255.3 TCP 3380 > http [ACK] Seq=405 Ack=1116 Win=64421 Len=0
Frame 10 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 405, Ack: 1116, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 405 (relative sequence number)
Acknowledgement number: 1116 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 64421
Checksum: 0x2f82 (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
11 0.018648 192.168.255.152 192.168.255.3 TCP 3380 > http [FIN, ACK] Seq=405 Ack=1116 Win=64421 Len=0
Frame 11 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 405, Ack: 1116, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 405 (relative sequence number)
Acknowledgement number: 1116 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
Window size: 64421
Checksum: 0x2f81 (correct)
No. Time Source Destination Protocol Info
12 0.018770 192.168.255.3 192.168.255.152 TCP http > 3380 [ACK] Seq=1116 Ack=406 Win=6432 Len=0
Frame 12 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 1116, Ack: 406, Len: 0
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 1116 (relative sequence number)
Acknowledgement number: 406 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0x1207 (correct)
SEQ/ACK analysis
[-- Attachment #3: no_work.cap --]
[-- Type: application/octet-stream, Size: 19008 bytes --]
No. Time Source Destination Protocol Info
1 0.000000 192.168.255.152 192.168.255.3 TCP 3379 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x7ef0 (correct)
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.000640 192.168.255.3 192.168.255.152 TCP http > 3379 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3379 (3379), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 5840
Checksum: 0x9e99 (correct)
Options: (8 bytes)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
3 0.000685 192.168.255.152 192.168.255.3 TCP 3379 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0xe22d (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
4 0.000814 192.168.255.152 192.168.255.3 HTTP GET /test/ HTTP/1.1
Frame 4 (458 bytes on wire, 458 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 1, Ack: 1, Len: 404
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 405 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0xcd59 (correct)
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.002538 192.168.255.3 192.168.255.152 TCP 1 > 3379 [ACK] Seq=0 Ack=0 Win=6432 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 0
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0xc7c8 (correct)
No. Time Source Destination Protocol Info
6 0.038891 192.168.255.3 192.168.255.152 TCP 1 > 3379 [PSH, ACK] Seq=0 Ack=0 Win=6432 Len=17
Frame 6 (71 bytes on wire, 71 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 17
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Next sequence number: 17 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 6432
Checksum: 0x07eb (correct)
Data (17 bytes)
0000 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f 4b 0d HTTP/1.0 200 OK.
0010 0a .
No. Time Source Destination Protocol Info
7 0.041106 192.168.255.3 192.168.255.152 TCP 1 > 3379 [FIN, PSH, ACK] Seq=17 Ack=0 Win=6432 Len=1097
Frame 7 (1151 bytes on wire, 1151 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 17, Ack: 0, Len: 1097
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 17 (relative sequence number)
Next sequence number: 1114 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0xc729 (correct)
Data (1097 bytes)
0000 44 61 74 65 3a 20 57 65 64 2c 20 32 33 20 4d 61 Date: Wed, 23 Ma
0010 72 20 32 30 30 35 20 32 30 3a 35 35 3a 35 39 20 r 2005 20:55:59
0020 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 61 GMT..Server: Apa
0030 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e 69 78 che/2.0.45 (Unix
0040 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 39 5f ) mod_perl/1.99_
0050 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 0d 0a 08 Perl/v5.6.1..
0060 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length:
0070 38 37 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 873..Content-Typ
0080 65 3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 e: text/html; ch
0090 61 72 73 65 74 3d 49 53 4f 2d 38 38 35 39 2d 31 arset=ISO-8859-1
00a0 0d 0a 58 2d 43 61 63 68 65 3a 20 4d 49 53 53 20 ..X-Cache: MISS
00b0 66 72 6f 6d 20 64 65 62 69 61 6e 2e 63 79 6d 70 from debian.cymp
00c0 68 6f 6e 69 78 2e 63 6f 6d 0d 0a 43 6f 6e 6e 65 honix.com..Conne
00d0 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 0d 0a ction: close....
00e0 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20 50 <!DOCTYPE HTML P
00f0 55 42 4c 49 43 20 22 2d 2f 2f 57 33 43 2f 2f 44 UBLIC "-//W3C//D
0100 54 44 20 48 54 4d 4c 20 33 2e 32 20 46 69 6e 61 TD HTML 3.2 Fina
0110 6c 2f 2f 45 4e 22 3e 0a 3c 68 74 6d 6c 3e 0a 20 l//EN">.<html>.
0120 3c 68 65 61 64 3e 0a 20 20 3c 74 69 74 6c 65 3e <head>. <title>
0130 49 6e 64 65 78 20 6f 66 20 2f 74 65 73 74 3c 2f Index of /test</
0140 74 69 74 6c 65 3e 0a 20 3c 2f 68 65 61 64 3e 0a title>. </head>.
0150 20 3c 62 6f 64 79 3e 0a 3c 68 31 3e 49 6e 64 65 <body>.<h1>Inde
0160 78 20 6f 66 20 2f 74 65 73 74 3c 2f 68 31 3e 0a x of /test</h1>.
0170 3c 70 72 65 3e 3c 69 6d 67 20 73 72 63 3d 22 2f <pre><img src="/
0180 69 63 6f 6e 73 2f 62 6c 61 6e 6b 2e 67 69 66 22 icons/blank.gif"
0190 20 61 6c 74 3d 22 49 63 6f 6e 20 22 20 2f 3e 20 alt="Icon " />
01a0 3c 61 20 68 72 65 66 3d 22 3f 43 3d 4e 26 61 6d <a href="?C=N&am
01b0 70 3b 4f 3d 44 22 3e 4e 61 6d 65 3c 2f 61 3e 20 p;O=D">Name</a>
01c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
01d0 20 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 4d <a href="?C=M
01e0 26 61 6d 70 3b 4f 3d 41 22 3e 4c 61 73 74 20 6d &O=A">Last m
01f0 6f 64 69 66 69 65 64 3c 2f 61 3e 20 20 20 20 20 odified</a>
0200 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 53 26 61 <a href="?C=S&a
0210 6d 70 3b 4f 3d 41 22 3e 53 69 7a 65 3c 2f 61 3e mp;O=A">Size</a>
0220 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 44 26 <a href="?C=D&
0230 61 6d 70 3b 4f 3d 41 22 3e 44 65 73 63 72 69 70 amp;O=A">Descrip
0240 74 69 6f 6e 3c 2f 61 3e 3c 68 72 20 2f 3e 3c 69 tion</a><hr /><i
0250 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 2f 62 mg src="/icons/b
0260 61 63 6b 2e 67 69 66 22 20 61 6c 74 3d 22 5b 44 ack.gif" alt="[D
0270 49 52 5d 22 20 2f 3e 20 3c 61 20 68 72 65 66 3d IR]" /> <a href=
0280 22 2f 22 3e 50 61 72 65 6e 74 20 44 69 72 65 63 "/">Parent Direc
0290 74 6f 72 79 3c 2f 61 3e 20 20 20 20 20 20 20 20 tory</a>
02a0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
02b0 20 20 20 20 20 2d 20 20 20 0a 3c 69 6d 67 20 73 - .<img s
02c0 72 63 3d 22 2f 69 63 6f 6e 73 2f 63 6f 6d 70 72 rc="/icons/compr
02d0 65 73 73 65 64 2e 67 69 66 22 20 61 6c 74 3d 22 essed.gif" alt="
02e0 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 68 72 65 [ ]" /> <a hre
02f0 66 3d 22 4c 69 66 65 2e 6f 66 2e 42 72 69 61 6e f="Life.of.Brian
0300 2e 44 56 44 52 69 70 2e 58 76 69 44 2d 49 63 65 .DVDRip.XviD-Ice
0310 2e 7a 69 70 22 3e 4c 69 66 65 2e 6f 66 2e 42 72 .zip">Life.of.Br
0320 69 61 6e 2e 44 56 44 52 69 70 2e 2e 26 67 74 3b ian.DVDRip..>
0330 3c 2f 61 3e 20 31 31 2d 4e 6f 76 2d 32 30 30 34 </a> 11-Nov-2004
0340 20 30 39 3a 35 34 20 20 37 30 30 4d 20 20 0a 3c 09:54 700M .<
0350 69 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 2f img src="/icons/
0360 75 6e 6b 6e 6f 77 6e 2e 67 69 66 22 20 61 6c 74 unknown.gif" alt
0370 3d 22 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 68 ="[ ]" /> <a h
0380 72 65 66 3d 22 54 65 6e 4d 65 67 2e 46 69 6c 65 ref="TenMeg.File
0390 22 3e 54 65 6e 4d 65 67 2e 46 69 6c 65 3c 2f 61 ">TenMeg.File</a
03a0 3e 20 20 20 20 20 20 20 20 20 20 20 20 20 32 33 > 23
03b0 2d 44 65 63 2d 32 30 30 33 20 30 32 3a 32 36 20 -Dec-2003 02:26
03c0 20 20 31 30 4d 20 20 0a 3c 68 72 20 2f 3e 3c 2f 10M .<hr /></
03d0 70 72 65 3e 0a 3c 61 64 64 72 65 73 73 3e 41 70 pre>.<address>Ap
03e0 61 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e 69 ache/2.0.45 (Uni
03f0 78 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 39 x) mod_perl/1.99
0400 5f 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 20 _08 Perl/v5.6.1
0410 53 65 72 76 65 72 20 61 74 20 31 39 32 2e 31 36 Server at 192.16
0420 38 2e 32 35 35 2e 33 20 50 6f 72 74 20 38 30 3c 8.255.3 Port 80<
0430 2f 61 64 64 72 65 73 73 3e 0a 3c 2f 62 6f 64 79 /address>.</body
0440 3e 3c 2f 68 74 6d 6c 3e 0a ></html>.
No. Time Source Destination Protocol Info
8 2.921155 192.168.255.152 192.168.255.3 HTTP GET /test/ HTTP/1.1
Frame 8 (458 bytes on wire, 458 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 1, Ack: 1, Len: 404
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 405 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0xcd59 (correct)
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
9 2.925412 192.168.255.3 192.168.255.152 TCP [TCP Dup ACK 5#1] 1 > 3379 [ACK] Seq=1115 Ack=0 Win=6432 Len=0 SLE=4294966892 SRE=0
Frame 9 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 1115, Ack: 0, Len: 0
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 1115 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 32 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0x9e43 (correct)
Options: (12 bytes)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
10 3.039180 192.168.255.3 192.168.255.152 TCP [TCP Retransmission] 1 > 3379 [FIN, PSH, ACK] Seq=0 Ack=0 Win=6432 Len=1114
Frame 10 (1168 bytes on wire, 1168 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 1114
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Next sequence number: 1114 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0xc7a4 (correct)
SEQ/ACK analysis
Data (1114 bytes)
0000 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f 4b 0d HTTP/1.0 200 OK.
0010 0a 44 61 74 65 3a 20 57 65 64 2c 20 32 33 20 4d .Date: Wed, 23 M
0020 61 72 20 32 30 30 35 20 32 30 3a 35 35 3a 35 39 ar 2005 20:55:59
0030 20 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 GMT..Server: Ap
0040 61 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e 69 ache/2.0.45 (Uni
0050 78 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 39 x) mod_perl/1.99
0060 5f 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 0d _08 Perl/v5.6.1.
0070 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
0080 20 38 37 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 873..Content-Ty
0090 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 63 pe: text/html; c
00a0 68 61 72 73 65 74 3d 49 53 4f 2d 38 38 35 39 2d harset=ISO-8859-
00b0 31 0d 0a 58 2d 43 61 63 68 65 3a 20 4d 49 53 53 1..X-Cache: MISS
00c0 20 66 72 6f 6d 20 64 65 62 69 61 6e 2e 63 79 6d from debian.cym
00d0 70 68 6f 6e 69 78 2e 63 6f 6d 0d 0a 43 6f 6e 6e phonix.com..Conn
00e0 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 0d ection: close...
00f0 0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20 .<!DOCTYPE HTML
0100 50 55 42 4c 49 43 20 22 2d 2f 2f 57 33 43 2f 2f PUBLIC "-//W3C//
0110 44 54 44 20 48 54 4d 4c 20 33 2e 32 20 46 69 6e DTD HTML 3.2 Fin
0120 61 6c 2f 2f 45 4e 22 3e 0a 3c 68 74 6d 6c 3e 0a al//EN">.<html>.
0130 20 3c 68 65 61 64 3e 0a 20 20 3c 74 69 74 6c 65 <head>. <title
0140 3e 49 6e 64 65 78 20 6f 66 20 2f 74 65 73 74 3c >Index of /test<
0150 2f 74 69 74 6c 65 3e 0a 20 3c 2f 68 65 61 64 3e /title>. </head>
0160 0a 20 3c 62 6f 64 79 3e 0a 3c 68 31 3e 49 6e 64 . <body>.<h1>Ind
0170 65 78 20 6f 66 20 2f 74 65 73 74 3c 2f 68 31 3e ex of /test</h1>
0180 0a 3c 70 72 65 3e 3c 69 6d 67 20 73 72 63 3d 22 .<pre><img src="
0190 2f 69 63 6f 6e 73 2f 62 6c 61 6e 6b 2e 67 69 66 /icons/blank.gif
01a0 22 20 61 6c 74 3d 22 49 63 6f 6e 20 22 20 2f 3e " alt="Icon " />
01b0 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 4e 26 61 <a href="?C=N&a
01c0 6d 70 3b 4f 3d 44 22 3e 4e 61 6d 65 3c 2f 61 3e mp;O=D">Name</a>
01d0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
01e0 20 20 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d <a href="?C=
01f0 4d 26 61 6d 70 3b 4f 3d 41 22 3e 4c 61 73 74 20 M&O=A">Last
0200 6d 6f 64 69 66 69 65 64 3c 2f 61 3e 20 20 20 20 modified</a>
0210 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 53 26 <a href="?C=S&
0220 61 6d 70 3b 4f 3d 41 22 3e 53 69 7a 65 3c 2f 61 amp;O=A">Size</a
0230 3e 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 44 > <a href="?C=D
0240 26 61 6d 70 3b 4f 3d 41 22 3e 44 65 73 63 72 69 &O=A">Descri
0250 70 74 69 6f 6e 3c 2f 61 3e 3c 68 72 20 2f 3e 3c ption</a><hr /><
0260 69 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 2f img src="/icons/
0270 62 61 63 6b 2e 67 69 66 22 20 61 6c 74 3d 22 5b back.gif" alt="[
0280 44 49 52 5d 22 20 2f 3e 20 3c 61 20 68 72 65 66 DIR]" /> <a href
0290 3d 22 2f 22 3e 50 61 72 65 6e 74 20 44 69 72 65 ="/">Parent Dire
02a0 63 74 6f 72 79 3c 2f 61 3e 20 20 20 20 20 20 20 ctory</a>
02b0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
02c0 20 20 20 20 20 20 2d 20 20 20 0a 3c 69 6d 67 20 - .<img
02d0 73 72 63 3d 22 2f 69 63 6f 6e 73 2f 63 6f 6d 70 src="/icons/comp
02e0 72 65 73 73 65 64 2e 67 69 66 22 20 61 6c 74 3d ressed.gif" alt=
02f0 22 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 68 72 "[ ]" /> <a hr
0300 65 66 3d 22 4c 69 66 65 2e 6f 66 2e 42 72 69 61 ef="Life.of.Bria
0310 6e 2e 44 56 44 52 69 70 2e 58 76 69 44 2d 49 63 n.DVDRip.XviD-Ic
0320 65 2e 7a 69 70 22 3e 4c 69 66 65 2e 6f 66 2e 42 e.zip">Life.of.B
0330 72 69 61 6e 2e 44 56 44 52 69 70 2e 2e 26 67 74 rian.DVDRip..>
0340 3b 3c 2f 61 3e 20 31 31 2d 4e 6f 76 2d 32 30 30 ;</a> 11-Nov-200
0350 34 20 30 39 3a 35 34 20 20 37 30 30 4d 20 20 0a 4 09:54 700M .
0360 3c 69 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 <img src="/icons
0370 2f 75 6e 6b 6e 6f 77 6e 2e 67 69 66 22 20 61 6c /unknown.gif" al
0380 74 3d 22 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 t="[ ]" /> <a
0390 68 72 65 66 3d 22 54 65 6e 4d 65 67 2e 46 69 6c href="TenMeg.Fil
03a0 65 22 3e 54 65 6e 4d 65 67 2e 46 69 6c 65 3c 2f e">TenMeg.File</
03b0 61 3e 20 20 20 20 20 20 20 20 20 20 20 20 20 32 a> 2
03c0 33 2d 44 65 63 2d 32 30 30 33 20 30 32 3a 32 36 3-Dec-2003 02:26
03d0 20 20 20 31 30 4d 20 20 0a 3c 68 72 20 2f 3e 3c 10M .<hr /><
03e0 2f 70 72 65 3e 0a 3c 61 64 64 72 65 73 73 3e 41 /pre>.<address>A
03f0 70 61 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e pache/2.0.45 (Un
0400 69 78 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 ix) mod_perl/1.9
0410 39 5f 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 9_08 Perl/v5.6.1
0420 20 53 65 72 76 65 72 20 61 74 20 31 39 32 2e 31 Server at 192.1
0430 36 38 2e 32 35 35 2e 33 20 50 6f 72 74 20 38 30 68.255.3 Port 80
0440 3c 2f 61 64 64 72 65 73 73 3e 0a 3c 2f 62 6f 64 </address>.</bod
0450 79 3e 3c 2f 68 74 6d 6c 3e 0a y></html>.
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
@ 2005-03-24 19:04 ` Trevor Paskett
0 siblings, 0 replies; 13+ messages in thread
From: Trevor Paskett @ 2005-03-24 19:04 UTC (permalink / raw)
To: gtaylor; +Cc: coreteam, netfilter, netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Thanks for your reply. Our product is a Linux based product that uses
netfilter. We have Squid and a filtering engine on our box. We are
strong supporters of netfilter. Our customers have many subnets behind
our box because of where it is placed in their network. Bringing up
alias's on br0 for each of their subnets that are not even on that
broadcast domain is a big band aid :). I think this is somehow a bug in
ip_nat_core.c and will investigate that further and have cc'd
coreteam@netfilter.org and hopefully that will get to Rusty who wrote
it.
As for the SNAT I think Jason Opperisano's response is correct.
Everything works great, except somewhere in ip_nat_core.c the src port
is getting changed to 1 from 80. I have attached an ethereal dump to
show this happening and a dump when it does what it is supposed to.
Everything between the 2 is the same, except after I captured the
no_work.cap, I did
ifconfig br0:0 192.168.255.165
So it had an IP on the test machine's subnet. Of course it worked fine
and that capture is work.cap
Thanks for all your help.
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
[-- Attachment #2: work.cap --]
[-- Type: application/octet-stream, Size: 10181 bytes --]
No. Time Source Destination Protocol Info
1 0.000000 192.168.255.152 192.168.255.3 TCP 3380 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x9e52 (correct)
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.000194 192.168.255.3 192.168.255.152 TCP http > 3380 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 5840
Checksum: 0xed82 (correct)
Options: (8 bytes)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
3 0.000240 192.168.255.152 192.168.255.3 TCP 3380 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x3117 (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
4 0.000625 192.168.255.152 192.168.255.3 HTTP GET /test/ HTTP/1.1
Frame 4 (458 bytes on wire, 458 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 1, Ack: 1, Len: 404
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 405 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1c43 (correct)
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.001738 192.168.255.3 192.168.255.152 TCP http > 3380 [ACK] Seq=1 Ack=405 Win=6432 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 1, Ack: 405, Len: 0
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 405 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0x1663 (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
6 0.006142 192.168.255.3 192.168.255.152 HTTP HTTP/1.0 200 OK (text/html)
Frame 6 (1168 bytes on wire, 1168 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 1114
Source port: http (80)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Next sequence number: 1114 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0xc754 (correct)
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
7 0.006193 192.168.255.152 192.168.255.3 TCP 3379 > http [RST, ACK] Seq=0 Ack=1114 Win=0 Len=0
Frame 7 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 0, Ack: 1114, Len: 0
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1114 (relative ack number)
Header length: 20 bytes
Flags: 0x0014 (RST, ACK)
Window size: 0
Checksum: 0xdc3a (correct)
No. Time Source Destination Protocol Info
8 0.012826 192.168.255.3 192.168.255.152 HTTP HTTP/1.0 200 OK
Frame 8 (71 bytes on wire, 71 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 1, Ack: 405, Len: 17
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 1 (relative sequence number)
Next sequence number: 18 (relative sequence number)
Acknowledgement number: 405 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 6432
Checksum: 0x5685 (correct)
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
9 0.014988 192.168.255.3 192.168.255.152 HTTP Continuation or non-HTTP traffic (text/html)
Frame 9 (1151 bytes on wire, 1151 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 18, Ack: 405, Len: 1097
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 18 (relative sequence number)
Next sequence number: 1115 (relative sequence number)
Acknowledgement number: 405 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0x1cc4 (correct)
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
10 0.015094 192.168.255.152 192.168.255.3 TCP 3380 > http [ACK] Seq=405 Ack=1116 Win=64421 Len=0
Frame 10 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 405, Ack: 1116, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 405 (relative sequence number)
Acknowledgement number: 1116 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 64421
Checksum: 0x2f82 (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
11 0.018648 192.168.255.152 192.168.255.3 TCP 3380 > http [FIN, ACK] Seq=405 Ack=1116 Win=64421 Len=0
Frame 11 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3380 (3380), Dst Port: http (80), Seq: 405, Ack: 1116, Len: 0
Source port: 3380 (3380)
Destination port: http (80)
Sequence number: 405 (relative sequence number)
Acknowledgement number: 1116 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
Window size: 64421
Checksum: 0x2f81 (correct)
No. Time Source Destination Protocol Info
12 0.018770 192.168.255.3 192.168.255.152 TCP http > 3380 [ACK] Seq=1116 Ack=406 Win=6432 Len=0
Frame 12 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:30:64:03:24:e7, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3380 (3380), Seq: 1116, Ack: 406, Len: 0
Source port: http (80)
Destination port: 3380 (3380)
Sequence number: 1116 (relative sequence number)
Acknowledgement number: 406 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0x1207 (correct)
SEQ/ACK analysis
[-- Attachment #3: no_work.cap --]
[-- Type: application/octet-stream, Size: 19008 bytes --]
No. Time Source Destination Protocol Info
1 0.000000 192.168.255.152 192.168.255.3 TCP 3379 > http [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x7ef0 (correct)
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.000640 192.168.255.3 192.168.255.152 TCP http > 3379 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: http (80), Dst Port: 3379 (3379), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 5840
Checksum: 0x9e99 (correct)
Options: (8 bytes)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
3 0.000685 192.168.255.152 192.168.255.3 TCP 3379 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0xe22d (correct)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
4 0.000814 192.168.255.152 192.168.255.3 HTTP GET /test/ HTTP/1.1
Frame 4 (458 bytes on wire, 458 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 1, Ack: 1, Len: 404
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 405 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0xcd59 (correct)
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.002538 192.168.255.3 192.168.255.152 TCP 1 > 3379 [ACK] Seq=0 Ack=0 Win=6432 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 0
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0xc7c8 (correct)
No. Time Source Destination Protocol Info
6 0.038891 192.168.255.3 192.168.255.152 TCP 1 > 3379 [PSH, ACK] Seq=0 Ack=0 Win=6432 Len=17
Frame 6 (71 bytes on wire, 71 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 17
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Next sequence number: 17 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 6432
Checksum: 0x07eb (correct)
Data (17 bytes)
0000 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f 4b 0d HTTP/1.0 200 OK.
0010 0a .
No. Time Source Destination Protocol Info
7 0.041106 192.168.255.3 192.168.255.152 TCP 1 > 3379 [FIN, PSH, ACK] Seq=17 Ack=0 Win=6432 Len=1097
Frame 7 (1151 bytes on wire, 1151 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 17, Ack: 0, Len: 1097
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 17 (relative sequence number)
Next sequence number: 1114 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0xc729 (correct)
Data (1097 bytes)
0000 44 61 74 65 3a 20 57 65 64 2c 20 32 33 20 4d 61 Date: Wed, 23 Ma
0010 72 20 32 30 30 35 20 32 30 3a 35 35 3a 35 39 20 r 2005 20:55:59
0020 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 61 GMT..Server: Apa
0030 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e 69 78 che/2.0.45 (Unix
0040 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 39 5f ) mod_perl/1.99_
0050 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 0d 0a 08 Perl/v5.6.1..
0060 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length:
0070 38 37 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 873..Content-Typ
0080 65 3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 e: text/html; ch
0090 61 72 73 65 74 3d 49 53 4f 2d 38 38 35 39 2d 31 arset=ISO-8859-1
00a0 0d 0a 58 2d 43 61 63 68 65 3a 20 4d 49 53 53 20 ..X-Cache: MISS
00b0 66 72 6f 6d 20 64 65 62 69 61 6e 2e 63 79 6d 70 from debian.cymp
00c0 68 6f 6e 69 78 2e 63 6f 6d 0d 0a 43 6f 6e 6e 65 honix.com..Conne
00d0 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 0d 0a ction: close....
00e0 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20 50 <!DOCTYPE HTML P
00f0 55 42 4c 49 43 20 22 2d 2f 2f 57 33 43 2f 2f 44 UBLIC "-//W3C//D
0100 54 44 20 48 54 4d 4c 20 33 2e 32 20 46 69 6e 61 TD HTML 3.2 Fina
0110 6c 2f 2f 45 4e 22 3e 0a 3c 68 74 6d 6c 3e 0a 20 l//EN">.<html>.
0120 3c 68 65 61 64 3e 0a 20 20 3c 74 69 74 6c 65 3e <head>. <title>
0130 49 6e 64 65 78 20 6f 66 20 2f 74 65 73 74 3c 2f Index of /test</
0140 74 69 74 6c 65 3e 0a 20 3c 2f 68 65 61 64 3e 0a title>. </head>.
0150 20 3c 62 6f 64 79 3e 0a 3c 68 31 3e 49 6e 64 65 <body>.<h1>Inde
0160 78 20 6f 66 20 2f 74 65 73 74 3c 2f 68 31 3e 0a x of /test</h1>.
0170 3c 70 72 65 3e 3c 69 6d 67 20 73 72 63 3d 22 2f <pre><img src="/
0180 69 63 6f 6e 73 2f 62 6c 61 6e 6b 2e 67 69 66 22 icons/blank.gif"
0190 20 61 6c 74 3d 22 49 63 6f 6e 20 22 20 2f 3e 20 alt="Icon " />
01a0 3c 61 20 68 72 65 66 3d 22 3f 43 3d 4e 26 61 6d <a href="?C=N&am
01b0 70 3b 4f 3d 44 22 3e 4e 61 6d 65 3c 2f 61 3e 20 p;O=D">Name</a>
01c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
01d0 20 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 4d <a href="?C=M
01e0 26 61 6d 70 3b 4f 3d 41 22 3e 4c 61 73 74 20 6d &O=A">Last m
01f0 6f 64 69 66 69 65 64 3c 2f 61 3e 20 20 20 20 20 odified</a>
0200 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 53 26 61 <a href="?C=S&a
0210 6d 70 3b 4f 3d 41 22 3e 53 69 7a 65 3c 2f 61 3e mp;O=A">Size</a>
0220 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 44 26 <a href="?C=D&
0230 61 6d 70 3b 4f 3d 41 22 3e 44 65 73 63 72 69 70 amp;O=A">Descrip
0240 74 69 6f 6e 3c 2f 61 3e 3c 68 72 20 2f 3e 3c 69 tion</a><hr /><i
0250 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 2f 62 mg src="/icons/b
0260 61 63 6b 2e 67 69 66 22 20 61 6c 74 3d 22 5b 44 ack.gif" alt="[D
0270 49 52 5d 22 20 2f 3e 20 3c 61 20 68 72 65 66 3d IR]" /> <a href=
0280 22 2f 22 3e 50 61 72 65 6e 74 20 44 69 72 65 63 "/">Parent Direc
0290 74 6f 72 79 3c 2f 61 3e 20 20 20 20 20 20 20 20 tory</a>
02a0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
02b0 20 20 20 20 20 2d 20 20 20 0a 3c 69 6d 67 20 73 - .<img s
02c0 72 63 3d 22 2f 69 63 6f 6e 73 2f 63 6f 6d 70 72 rc="/icons/compr
02d0 65 73 73 65 64 2e 67 69 66 22 20 61 6c 74 3d 22 essed.gif" alt="
02e0 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 68 72 65 [ ]" /> <a hre
02f0 66 3d 22 4c 69 66 65 2e 6f 66 2e 42 72 69 61 6e f="Life.of.Brian
0300 2e 44 56 44 52 69 70 2e 58 76 69 44 2d 49 63 65 .DVDRip.XviD-Ice
0310 2e 7a 69 70 22 3e 4c 69 66 65 2e 6f 66 2e 42 72 .zip">Life.of.Br
0320 69 61 6e 2e 44 56 44 52 69 70 2e 2e 26 67 74 3b ian.DVDRip..>
0330 3c 2f 61 3e 20 31 31 2d 4e 6f 76 2d 32 30 30 34 </a> 11-Nov-2004
0340 20 30 39 3a 35 34 20 20 37 30 30 4d 20 20 0a 3c 09:54 700M .<
0350 69 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 2f img src="/icons/
0360 75 6e 6b 6e 6f 77 6e 2e 67 69 66 22 20 61 6c 74 unknown.gif" alt
0370 3d 22 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 68 ="[ ]" /> <a h
0380 72 65 66 3d 22 54 65 6e 4d 65 67 2e 46 69 6c 65 ref="TenMeg.File
0390 22 3e 54 65 6e 4d 65 67 2e 46 69 6c 65 3c 2f 61 ">TenMeg.File</a
03a0 3e 20 20 20 20 20 20 20 20 20 20 20 20 20 32 33 > 23
03b0 2d 44 65 63 2d 32 30 30 33 20 30 32 3a 32 36 20 -Dec-2003 02:26
03c0 20 20 31 30 4d 20 20 0a 3c 68 72 20 2f 3e 3c 2f 10M .<hr /></
03d0 70 72 65 3e 0a 3c 61 64 64 72 65 73 73 3e 41 70 pre>.<address>Ap
03e0 61 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e 69 ache/2.0.45 (Uni
03f0 78 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 39 x) mod_perl/1.99
0400 5f 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 20 _08 Perl/v5.6.1
0410 53 65 72 76 65 72 20 61 74 20 31 39 32 2e 31 36 Server at 192.16
0420 38 2e 32 35 35 2e 33 20 50 6f 72 74 20 38 30 3c 8.255.3 Port 80<
0430 2f 61 64 64 72 65 73 73 3e 0a 3c 2f 62 6f 64 79 /address>.</body
0440 3e 3c 2f 68 74 6d 6c 3e 0a ></html>.
No. Time Source Destination Protocol Info
8 2.921155 192.168.255.152 192.168.255.3 HTTP GET /test/ HTTP/1.1
Frame 8 (458 bytes on wire, 458 bytes captured)
Ethernet II, Src: 00:0c:76:3d:08:67, Dst: 00:04:23:09:90:2c
Internet Protocol, Src Addr: 192.168.255.152 (192.168.255.152), Dst Addr: 192.168.255.3 (192.168.255.3)
Transmission Control Protocol, Src Port: 3379 (3379), Dst Port: http (80), Seq: 1, Ack: 1, Len: 404
Source port: 3379 (3379)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 405 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0xcd59 (correct)
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
9 2.925412 192.168.255.3 192.168.255.152 TCP [TCP Dup ACK 5#1] 1 > 3379 [ACK] Seq=1115 Ack=0 Win=6432 Len=0 SLE=4294966892 SRE=0
Frame 9 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 1115, Ack: 0, Len: 0
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 1115 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 32 bytes
Flags: 0x0010 (ACK)
Window size: 6432
Checksum: 0x9e43 (correct)
Options: (12 bytes)
SEQ/ACK analysis
No. Time Source Destination Protocol Info
10 3.039180 192.168.255.3 192.168.255.152 TCP [TCP Retransmission] 1 > 3379 [FIN, PSH, ACK] Seq=0 Ack=0 Win=6432 Len=1114
Frame 10 (1168 bytes on wire, 1168 bytes captured)
Ethernet II, Src: 00:04:75:86:a8:3e, Dst: 00:0c:76:3d:08:67
Internet Protocol, Src Addr: 192.168.255.3 (192.168.255.3), Dst Addr: 192.168.255.152 (192.168.255.152)
Transmission Control Protocol, Src Port: 1 (1), Dst Port: 3379 (3379), Seq: 0, Ack: 0, Len: 1114
Source port: 1 (1)
Destination port: 3379 (3379)
Sequence number: 0 (relative sequence number)
Next sequence number: 1114 (relative sequence number)
Acknowledgement number: 0 (relative ack number)
Header length: 20 bytes
Flags: 0x0019 (FIN, PSH, ACK)
Window size: 6432
Checksum: 0xc7a4 (correct)
SEQ/ACK analysis
Data (1114 bytes)
0000 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f 4b 0d HTTP/1.0 200 OK.
0010 0a 44 61 74 65 3a 20 57 65 64 2c 20 32 33 20 4d .Date: Wed, 23 M
0020 61 72 20 32 30 30 35 20 32 30 3a 35 35 3a 35 39 ar 2005 20:55:59
0030 20 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 GMT..Server: Ap
0040 61 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e 69 ache/2.0.45 (Uni
0050 78 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 39 x) mod_perl/1.99
0060 5f 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 0d _08 Perl/v5.6.1.
0070 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
0080 20 38 37 33 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 873..Content-Ty
0090 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 63 pe: text/html; c
00a0 68 61 72 73 65 74 3d 49 53 4f 2d 38 38 35 39 2d harset=ISO-8859-
00b0 31 0d 0a 58 2d 43 61 63 68 65 3a 20 4d 49 53 53 1..X-Cache: MISS
00c0 20 66 72 6f 6d 20 64 65 62 69 61 6e 2e 63 79 6d from debian.cym
00d0 70 68 6f 6e 69 78 2e 63 6f 6d 0d 0a 43 6f 6e 6e phonix.com..Conn
00e0 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 0d 0a 0d ection: close...
00f0 0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20 .<!DOCTYPE HTML
0100 50 55 42 4c 49 43 20 22 2d 2f 2f 57 33 43 2f 2f PUBLIC "-//W3C//
0110 44 54 44 20 48 54 4d 4c 20 33 2e 32 20 46 69 6e DTD HTML 3.2 Fin
0120 61 6c 2f 2f 45 4e 22 3e 0a 3c 68 74 6d 6c 3e 0a al//EN">.<html>.
0130 20 3c 68 65 61 64 3e 0a 20 20 3c 74 69 74 6c 65 <head>. <title
0140 3e 49 6e 64 65 78 20 6f 66 20 2f 74 65 73 74 3c >Index of /test<
0150 2f 74 69 74 6c 65 3e 0a 20 3c 2f 68 65 61 64 3e /title>. </head>
0160 0a 20 3c 62 6f 64 79 3e 0a 3c 68 31 3e 49 6e 64 . <body>.<h1>Ind
0170 65 78 20 6f 66 20 2f 74 65 73 74 3c 2f 68 31 3e ex of /test</h1>
0180 0a 3c 70 72 65 3e 3c 69 6d 67 20 73 72 63 3d 22 .<pre><img src="
0190 2f 69 63 6f 6e 73 2f 62 6c 61 6e 6b 2e 67 69 66 /icons/blank.gif
01a0 22 20 61 6c 74 3d 22 49 63 6f 6e 20 22 20 2f 3e " alt="Icon " />
01b0 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 4e 26 61 <a href="?C=N&a
01c0 6d 70 3b 4f 3d 44 22 3e 4e 61 6d 65 3c 2f 61 3e mp;O=D">Name</a>
01d0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
01e0 20 20 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d <a href="?C=
01f0 4d 26 61 6d 70 3b 4f 3d 41 22 3e 4c 61 73 74 20 M&O=A">Last
0200 6d 6f 64 69 66 69 65 64 3c 2f 61 3e 20 20 20 20 modified</a>
0210 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 53 26 <a href="?C=S&
0220 61 6d 70 3b 4f 3d 41 22 3e 53 69 7a 65 3c 2f 61 amp;O=A">Size</a
0230 3e 20 20 3c 61 20 68 72 65 66 3d 22 3f 43 3d 44 > <a href="?C=D
0240 26 61 6d 70 3b 4f 3d 41 22 3e 44 65 73 63 72 69 &O=A">Descri
0250 70 74 69 6f 6e 3c 2f 61 3e 3c 68 72 20 2f 3e 3c ption</a><hr /><
0260 69 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 2f img src="/icons/
0270 62 61 63 6b 2e 67 69 66 22 20 61 6c 74 3d 22 5b back.gif" alt="[
0280 44 49 52 5d 22 20 2f 3e 20 3c 61 20 68 72 65 66 DIR]" /> <a href
0290 3d 22 2f 22 3e 50 61 72 65 6e 74 20 44 69 72 65 ="/">Parent Dire
02a0 63 74 6f 72 79 3c 2f 61 3e 20 20 20 20 20 20 20 ctory</a>
02b0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
02c0 20 20 20 20 20 20 2d 20 20 20 0a 3c 69 6d 67 20 - .<img
02d0 73 72 63 3d 22 2f 69 63 6f 6e 73 2f 63 6f 6d 70 src="/icons/comp
02e0 72 65 73 73 65 64 2e 67 69 66 22 20 61 6c 74 3d ressed.gif" alt=
02f0 22 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 68 72 "[ ]" /> <a hr
0300 65 66 3d 22 4c 69 66 65 2e 6f 66 2e 42 72 69 61 ef="Life.of.Bria
0310 6e 2e 44 56 44 52 69 70 2e 58 76 69 44 2d 49 63 n.DVDRip.XviD-Ic
0320 65 2e 7a 69 70 22 3e 4c 69 66 65 2e 6f 66 2e 42 e.zip">Life.of.B
0330 72 69 61 6e 2e 44 56 44 52 69 70 2e 2e 26 67 74 rian.DVDRip..>
0340 3b 3c 2f 61 3e 20 31 31 2d 4e 6f 76 2d 32 30 30 ;</a> 11-Nov-200
0350 34 20 30 39 3a 35 34 20 20 37 30 30 4d 20 20 0a 4 09:54 700M .
0360 3c 69 6d 67 20 73 72 63 3d 22 2f 69 63 6f 6e 73 <img src="/icons
0370 2f 75 6e 6b 6e 6f 77 6e 2e 67 69 66 22 20 61 6c /unknown.gif" al
0380 74 3d 22 5b 20 20 20 5d 22 20 2f 3e 20 3c 61 20 t="[ ]" /> <a
0390 68 72 65 66 3d 22 54 65 6e 4d 65 67 2e 46 69 6c href="TenMeg.Fil
03a0 65 22 3e 54 65 6e 4d 65 67 2e 46 69 6c 65 3c 2f e">TenMeg.File</
03b0 61 3e 20 20 20 20 20 20 20 20 20 20 20 20 20 32 a> 2
03c0 33 2d 44 65 63 2d 32 30 30 33 20 30 32 3a 32 36 3-Dec-2003 02:26
03d0 20 20 20 31 30 4d 20 20 0a 3c 68 72 20 2f 3e 3c 10M .<hr /><
03e0 2f 70 72 65 3e 0a 3c 61 64 64 72 65 73 73 3e 41 /pre>.<address>A
03f0 70 61 63 68 65 2f 32 2e 30 2e 34 35 20 28 55 6e pache/2.0.45 (Un
0400 69 78 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e 39 ix) mod_perl/1.9
0410 39 5f 30 38 20 50 65 72 6c 2f 76 35 2e 36 2e 31 9_08 Perl/v5.6.1
0420 20 53 65 72 76 65 72 20 61 74 20 31 39 32 2e 31 Server at 192.1
0430 36 38 2e 32 35 35 2e 33 20 50 6f 72 74 20 38 30 68.255.3 Port 80
0440 3c 2f 61 64 64 72 65 73 73 3e 0a 3c 2f 62 6f 64 </address>.</bod
0450 79 3e 3c 2f 68 74 6d 6c 3e 0a y></html>.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
[not found] <2F413D5F33545D4A8465BBEE900238CC3FA777@cymmail.cymphonix.com>
` (3 preceding siblings ...)
2005-03-24 8:50 ` Grant Taylor
@ 2005-03-24 21:09 ` Grant Taylor
4 siblings, 0 replies; 13+ messages in thread
From: Grant Taylor @ 2005-03-24 21:09 UTC (permalink / raw)
To: Trevor Paskett; +Cc: coreteam, netfilter
There is one last really dastardly thing that I think *might* work. That would be running your system with a UML in side of it that does nothing but DNATing/SNATing of traffic coming in to it so that traffic could be redirected right back to Squid and then out and back through the DNAT/SNAT router and then back to the box it's self where things can be handled. But when I start thinking of things like this I also start thinking that there is something either missing or broken that is preventing me from doing what I want to do, but sometimes things like this are necessary. I presently do not have a system set up any where to test this and I will not have time to do so for a while. If you would like me to continue down this road next week I would be willing to do so. In short the following would be the packet's path through the network:
Client System(s) <-> Linux 2.6.9 System (DNAT/SNAT) <-> Linux 2.6.9 UML (DNAT/SNAT) <-> Squid on Linux 2.6.9 System <-> Linux 2.6.9 UML (DNAT/SNAT) <-> Linux 2.6.9 System (DNAT/SNAT) <-> INet Router <-> Client System(s)
Yes this is a LONG convoluted path, but this is all that I can think of with out really messing with the packet. I have had reasonable success running UMLs for routing before as I have a client that routes out across 8 cable modems on the same subnet in a pseudo round robin fashion via routing to 8 UML virtual routers and then bridging back to the interfaces that the cable modems are connected to. I ended up using 802.1q VLAN tagging to create the 8 virtual interfaces with wonderful success. So things like this are doable, just cumbersome and I've not seen any network config or firewall package that would even come close to doing things like this. This is all hand rolled stuff.
Grant. . . .
Trevor Paskett wrote:
> Thanks for your reply. Our product is a Linux based product that uses
> netfilter. We have Squid and a filtering engine on our box. We are
> strong supporters of netfilter. Our customers have many subnets behind
> our box because of where it is placed in their network. Bringing up
> alias's on br0 for each of their subnets that are not even on that
> broadcast domain is a big band aid :). I think this is somehow a bug in
> ip_nat_core.c and will investigate that further and have cc'd
> coreteam@netfilter.org and hopefully that will get to Rusty who wrote
> it.
>
> As for the SNAT I think Jason Opperisano's response is correct.
> Everything works great, except somewhere in ip_nat_core.c the src port
> is getting changed to 1 from 80. I have attached an ethereal dump to
> show this happening and a dump when it does what it is supposed to.
> Everything between the 2 is the same, except after I captured the
> no_work.cap, I did
>
> ifconfig br0:0 192.168.255.165
>
> So it had an IP on the test machine's subnet. Of course it worked fine
> and that capture is work.cap
>
> Thanks for all your help.
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet
@ 2005-03-25 21:30 Trevor Paskett
0 siblings, 0 replies; 13+ messages in thread
From: Trevor Paskett @ 2005-03-25 21:30 UTC (permalink / raw)
To: gtaylor; +Cc: coreteam, netfilter
[-- Attachment #1: Type: text/plain, Size: 3568 bytes --]
I have found a solution :)
It was missing a route. If I do
ip route add 192.168.255.0/24 dev br0
For the remote subnets everything works as it should. Thanks for everyone's
help!!
Trevor Paskett
Cymphonix Programmer - CCNA, CWNA
P: 801-938-1500 F: 801-938-1501
-----Original Message-----
From: Grant Taylor [mailto:gtaylor@riverviewtech.net]
Sent: Thursday, March 24, 2005 1:10 PM
To: Trevor Paskett
Cc: netfilter@lists.netfilter.org; coreteam@netfilter.org
Subject: Re: HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on
different subnet
There is one last really dastardly thing that I think *might* work. That
would be running your system with a UML in side of it that does nothing but
DNATing/SNATing of traffic coming in to it so that traffic could be
redirected right back to Squid and then out and back through the DNAT/SNAT
router and then back to the box it's self where things can be handled. But
when I start thinking of things like this I also start thinking that there
is something either missing or broken that is preventing me from doing what
I want to do, but sometimes things like this are necessary. I presently do
not have a system set up any where to test this and I will not have time to
do so for a while. If you would like me to continue down this road next
week I would be willing to do so. In short the following would be the
packet's path through the network:
Client System(s) <-> Linux 2.6.9 System (DNAT/SNAT) <-> Linux 2.6.9 UML
(DNAT/SNAT) <-> Squid on Linux 2.6.9 System <-> Linux 2.6.9 UML (DNAT/SNAT)
<-> Linux 2.6.9 System (DNAT/SNAT) <-> INet Router <-> Client System(s)
Yes this is a LONG convoluted path, but this is all that I can think of with
out really messing with the packet. I have had reasonable success running
UMLs for routing before as I have a client that routes out across 8 cable
modems on the same subnet in a pseudo round robin fashion via routing to 8
UML virtual routers and then bridging back to the interfaces that the cable
modems are connected to. I ended up using 802.1q VLAN tagging to create the
8 virtual interfaces with wonderful success. So things like this are
doable, just cumbersome and I've not seen any network config or firewall
package that would even come close to doing things like this. This is all
hand rolled stuff.
Grant. . . .
Trevor Paskett wrote:
> Thanks for your reply. Our product is a Linux based product that uses
> netfilter. We have Squid and a filtering engine on our box. We are
> strong supporters of netfilter. Our customers have many subnets behind
> our box because of where it is placed in their network. Bringing up
> alias's on br0 for each of their subnets that are not even on that
> broadcast domain is a big band aid :). I think this is somehow a bug in
> ip_nat_core.c and will investigate that further and have cc'd
> coreteam@netfilter.org and hopefully that will get to Rusty who wrote
> it.
>
> As for the SNAT I think Jason Opperisano's response is correct.
> Everything works great, except somewhere in ip_nat_core.c the src port
> is getting changed to 1 from 80. I have attached an ethereal dump to
> show this happening and a dump when it does what it is supposed to.
> Everything between the 2 is the same, except after I captured the
> no_work.cap, I did
>
> ifconfig br0:0 192.168.255.165
>
> So it had an IP on the test machine's subnet. Of course it worked fine
> and that capture is work.cap
>
> Thanks for all your help.
>
> Trevor Paskett
> Cymphonix Programmer - CCNA, CWNA
> P: 801-938-1500 F: 801-938-1501
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3034 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-03-25 21:30 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-23 17:08 HELP! Transparent Proxy using bridging 2.6.9 and REDIRECT on different subnet Trevor Paskett
2005-03-23 17:08 ` Trevor Paskett
2005-03-23 19:24 ` Grant Taylor
2005-03-23 19:42 ` Jason Opperisano
-- strict thread matches above, loose matches on Subject: below --
2005-03-23 19:18 Trevor Paskett
[not found] <2F413D5F33545D4A8465BBEE900238CC3FA777@cymmail.cymphonix.com>
2005-03-23 23:50 ` Grant Taylor
2005-03-24 0:35 ` Grant Taylor
2005-03-24 6:25 ` Grant Taylor
2005-03-24 8:50 ` Grant Taylor
2005-03-24 21:09 ` Grant Taylor
2005-03-24 19:04 Trevor Paskett
2005-03-24 19:04 ` Trevor Paskett
2005-03-25 21:30 Trevor Paskett
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.