Re: [tproxy] Fwd: Tproxy changes for performing dual NAT
Hi, On Mon, Oct 15, 2007 at 04:30:03PM +0530, Arun S wrote:
I am not aware of this. I have tried tproxy4.0.3 and Squid-2.6-STABLE14. But real transparency was not happening. Does it require support from the application too?
Yes, and the modifications it requires are different compared to those of required by tproxy2.
Could you please throw some light on this?
I don't have a patch for squid at the moment but creating one should be quite straigtforward. I'll try to come up with one once I find the time to do so. A very brief README: http://marc.info/?l=linux-netdev&m=119229721212273&w=2 As an example, here's the patch necessary to make netcat work: http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patc... -- KOVACS Krisztian
Hi, On Mon, Oct 15, 2007 at 01:22:26PM +0200, KOVACS Krisztian wrote:
On Mon, Oct 15, 2007 at 04:30:03PM +0530, Arun S wrote:
I am not aware of this. I have tried tproxy4.0.3 and Squid-2.6-STABLE14. But real transparency was not happening. Does it require support from the application too?
Yes, and the modifications it requires are different compared to those of required by tproxy2.
Could you please throw some light on this?
I don't have a patch for squid at the moment but creating one should be quite straigtforward. I'll try to come up with one once I find the time to do so.
A very brief README: http://marc.info/?l=linux-netdev&m=119229721212273&w=2
As an example, here's the patch necessary to make netcat work: http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patc...
Oh, sorry -- in case of 4.0.3 these are not the right pointers. Take a look at the documentation and examples which come with the downloaded package. -- KOVACS Krisztian
What is the correct version of squid for implementation of tproxy 4.03. ----- Original Message ----- From: "KOVACS Krisztian" <hidden@sch.bme.hu> To: "Arun S" <hi2arun@gmail.com> Cc: <tproxy@lists.balabit.hu> Sent: Monday, October 15, 2007 8:26 AM Subject: Re: [tproxy] Fwd: Tproxy changes for performing dual NAT
Hi,
On Mon, Oct 15, 2007 at 01:22:26PM +0200, KOVACS Krisztian wrote:
On Mon, Oct 15, 2007 at 04:30:03PM +0530, Arun S wrote:
I am not aware of this. I have tried tproxy4.0.3 and Squid-2.6-STABLE14. But real transparency was not happening. Does it require support from the application too?
Yes, and the modifications it requires are different compared to those of required by tproxy2.
Could you please throw some light on this?
I don't have a patch for squid at the moment but creating one should be quite straigtforward. I'll try to come up with one once I find the time to do so.
A very brief README: http://marc.info/?l=linux-netdev&m=119229721212273&w=2
As an example, here's the patch necessary to make netcat work: http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patc...
Oh, sorry -- in case of 4.0.3 these are not the right pointers. Take a look at the documentation and examples which come with the downloaded package.
-- KOVACS Krisztian _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
I don't know anything about squid with TProxy. I asked this question at squid-dev mailing list. http://www.squid-cache.org/Support/mailing-lists.dyn On 2007.10.15., at 13:51, Herlon Alcantara Matos wrote:
What is the correct version of squid for implementation of tproxy 4.03.
-- Laszlo Attila Toth panther@balabit.hu
AFAIK, Squid still uses setsockopt - IP_TPROXY. It is yet to support IP_TRANSPARENT changes. On 15/10/2007, Herlon Alcantara Matos <herlon@lcimt.com.br> wrote:
What is the correct version of squid for implementation of tproxy 4.03.
----- Original Message ----- From: "KOVACS Krisztian" <hidden@sch.bme.hu> To: "Arun S" <hi2arun@gmail.com> Cc: <tproxy@lists.balabit.hu> Sent: Monday, October 15, 2007 8:26 AM Subject: Re: [tproxy] Fwd: Tproxy changes for performing dual NAT
Hi,
On Mon, Oct 15, 2007 at 01:22:26PM +0200, KOVACS Krisztian wrote:
On Mon, Oct 15, 2007 at 04:30:03PM +0530, Arun S wrote:
I am not aware of this. I have tried tproxy4.0.3 and Squid-2.6-STABLE14. But real transparency was not happening. Does it require support from the application too?
Yes, and the modifications it requires are different compared to those of required by tproxy2.
Could you please throw some light on this?
I don't have a patch for squid at the moment but creating one should be quite straigtforward. I'll try to come up with one once I find the time to do so.
A very brief README: http://marc.info/?l=linux-netdev&m=119229721212273&w=2
As an example, here's the patch necessary to make netcat work: http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patc...
Oh, sorry -- in case of 4.0.3 these are not the right pointers. Take a look at the documentation and examples which come with the downloaded package.
-- KOVACS Krisztian _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy
-- Regards, Arun S.
Hi, In which version of linux kernel, can we expect the latest tproxy changes to come? On 15/10/2007, KOVACS Krisztian <hidden@sch.bme.hu> wrote:
Hi,
On Mon, Oct 15, 2007 at 01:22:26PM +0200, KOVACS Krisztian wrote:
On Mon, Oct 15, 2007 at 04:30:03PM +0530, Arun S wrote:
I am not aware of this. I have tried tproxy4.0.3 and Squid-2.6-STABLE14. But real transparency was not happening. Does it require support from the application too?
Yes, and the modifications it requires are different compared to those of required by tproxy2.
Could you please throw some light on this?
I don't have a patch for squid at the moment but creating one should be quite straigtforward. I'll try to come up with one once I find the time to do so.
A very brief README: http://marc.info/?l=linux-netdev&m=119229721212273&w=2
As an example, here's the patch necessary to make netcat work: http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patc...
Oh, sorry -- in case of 4.0.3 these are not the right pointers. Take a look at the documentation and examples which come with the downloaded package.
-- KOVACS Krisztian
-- Regards, Arun S.
Hello, On 2007.10.15., at 15:04, Arun S wrote:
In which version of linux kernel, can we expect the latest tproxy changes to come?
It seems not before 2.6.25. But that's quite far from now. -- Laszlo Attila Toth panther@balabit.hu
Hi Attila / Krisztian, Could you please tell me which version of linux kernel shall I use to try the latest tproxy4 changes and from where shall I get the latest tproxy4 patches? TIA Arun S. On 15/10/2007, Tóth László Attila <panther@balabit.hu> wrote:
Hello,
On 2007.10.15., at 15:04, Arun S wrote:
In which version of linux kernel, can we expect the latest tproxy changes to come?
It seems not before 2.6.25. But that's quite far from now.
-- Laszlo Attila Toth panther@balabit.hu
-- Regards, Arun S.
Hello, On 2007.10.22., at 18:51, Arun S wrote:
Hi Attila / Krisztian,
Could you please tell me which version of linux kernel shall I use to try the latest tproxy4 changes and from where shall I get the latest tproxy4 patches?
2.6.23 should be ok with both version: at www.balabit.com and at http://people.netfilter.org/hidden/tproxy/ The first one is tested for 2.6.22 only. How can it enabled in squid: I don't know the source code but it requires no secial code with TProxy4 except set the IP_TRANSPARENT socket option for lisening socket. It is a new option: #define IP_TRANSPARENT 19 HTH, Attila
Hi, Thank you. I will get this downloaded and try to tweak Squid to work for the latest tproxy4 changes. Will let you know the changes in Squid once I manage to get Squid compiled for tproxy4. On 22/10/2007, Tóth László Attila <panther@elte.hu> wrote:
Hello,
On 2007.10.22., at 18:51, Arun S wrote:
Hi Attila / Krisztian,
Could you please tell me which version of linux kernel shall I use to try the latest tproxy4 changes and from where shall I get the latest tproxy4 patches?
2.6.23 should be ok with both version: at www.balabit.com and at http://people.netfilter.org/hidden/tproxy/ The first one is tested for 2.6.22 only.
How can it enabled in squid: I don't know the source code but it requires no secial code with TProxy4 except set the IP_TRANSPARENT socket option for lisening socket. It is a new option: #define IP_TRANSPARENT 19
HTH, Attila
-- Regards, Arun S.
Hi Kovacs/Attila, I have successfully applied your patches tproxy4-2.6.22_20070622.tar.bz2 on linux-2.6.22 and got all the modules compiled. Also iptables-1.4.0rc1 is applied with the patch iptables-tproxy-200710091749.diff. But I get error while adding the following rule: [root@Arun-FC6-SQUID linux-tproxy4-RnD]# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark iptables v1.4.0rc1: Unknown arg `--tproxy-mark' Try `iptables -h' or 'iptables --help' for more information. [root@Arun-FC6-SQUID linux-tproxy4-RnD]# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3128 iptables: Invalid argument Am I missing anything? TIA. Regards, Arun S. On 23/10/2007, Arun S <hi2arun@gmail.com> wrote:
Hi,
Thank you. I will get this downloaded and try to tweak Squid to work for the latest tproxy4 changes.
Will let you know the changes in Squid once I manage to get Squid compiled for tproxy4.
On 22/10/2007, Tóth László Attila <panther@elte.hu> wrote:
Hello,
On 2007.10.22., at 18:51, Arun S wrote:
Hi Attila / Krisztian,
Could you please tell me which version of linux kernel shall I use to try the latest tproxy4 changes and from where shall I get the latest tproxy4 patches?
2.6.23 should be ok with both version: at www.balabit.com and at http://people.netfilter.org/hidden/tproxy/ The first one is tested for 2.6.22 only.
How can it enabled in squid: I don't know the source code but it requires no secial code with TProxy4 except set the IP_TRANSPARENT socket option for lisening socket. It is a new option: #define IP_TRANSPARENT 19
HTH, Attila
-- Regards, Arun S.
-- Regards, Arun S.
Hello, Arun S írta:
Hi Kovacs/Attila,
I have successfully applied your patches tproxy4-2.6.22_20070622.tar.bz2 on linux-2.6.22 and got all the modules compiled.
Also iptables-1.4.0rc1 is applied with the patch iptables-tproxy-200710091749.diff.
But I get error while adding the following rule:
[root@Arun-FC6-SQUID linux-tproxy4-RnD]# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark iptables v1.4.0rc1: Unknown arg `--tproxy-mark' Try `iptables -h' or 'iptables --help' for more information.
The latest patches are here: http://people.netfilter.org/hidden/tproxy/ You downloaded an old version of the kernel patches without tproxy-mark support and a new version of the iptables patches with tproxy-mark support. Attila
Oops! Shall I go ahead with linux-2.6.23.tar.bz2 and tproxy4-2.6.23-200710090922.tar.bz2 ? On 26/10/2007, Laszlo Attila Toth <panther@balabit.hu> wrote:
Hello,
Arun S írta:
Hi Kovacs/Attila,
I have successfully applied your patches tproxy4-2.6.22_20070622.tar.bz2 on linux-2.6.22 and got all the modules compiled.
Also iptables-1.4.0rc1 is applied with the patch iptables-tproxy-200710091749.diff.
But I get error while adding the following rule:
[root@Arun-FC6-SQUID linux-tproxy4-RnD]# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark iptables v1.4.0rc1: Unknown arg `--tproxy-mark' Try `iptables -h' or 'iptables --help' for more information.
The latest patches are here: http://people.netfilter.org/hidden/tproxy/
You downloaded an old version of the kernel patches without tproxy-mark support and a new version of the iptables patches with tproxy-mark support.
Attila
-- Regards, Arun S.
Arun S írta:
Oops!
Shall I go ahead with linux-2.6.23.tar.bz2 and tproxy4-2.6.23-200710090922.tar.bz2 ?
Yes... If you mean these two: http://people.netfilter.org/hidden/tproxy/iptables-tproxy-200710091749.diff http://people.netfilter.org/hidden/tproxy/tproxy4-2.6.23-200710090922.tar.bz... -- Panther
Hi Attila, I have a problem with tproxy4 that I downloaded from the given links. Setup: LAN1: eth0: 20.20.20.4/24 TPROXYGw: eth1: 20.20.20.1/24 eth0: 30.0.1.1/24 WWW: eth0: 30.0.1.3/24 LAN1 <-----------> TPROXYGw <--------------> WWW TPROXYGw runs a sample proxy server (with IP_TRANSPARENT socket option enabled) that listens on TCP port 8080. Scenario 1: Testing normal TPROXY functionality: The following ip and iptable rules are added: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 8080 Output: [root@Arun-FC6-SQUID ~]# ./listIpt.sh MANGLE Chain PREROUTING (policy ACCEPT 27615 packets, 2707393 bytes) pkts bytes target prot opt in out source destination 1129 98288 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 0 0 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 0.0.0.0:8080 mark 0x1/0x1 Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 1132 98460 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK set 0x1 1132 98460 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 [root@Arun-FC6-SQUID ~]# ip rule show 0: from all lookup local 32765: from all fwmark 0x1 lookup 100 32766: from all lookup main 32767: from all lookup default In this case, TPROXY stuff is working properly. PS: A route to 30.0.1.1 on WWW was added for network 20.20.20.0/24 [root@Arun-FC6-WWW ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.30.11.96 0.0.0.0 255.255.255.224 U 0 0 0 eth0 20.20.20.0 30.0.1.1 255.255.255.0 UG 0 0 0 eth0 30.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 172.30.11.97 0.0.0.0 UG 0 0 0 eth0 Scenario 2: Testing SNAT with TPROXY: The following ip and iptable rules are added: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 8080 iptables -t nat -A POSTROUTING -o eth0 -s 20.20.20.4 -j SNAT --to 95.75.75.104 Output: [root@Arun-FC6-SQUID ~]# ./listIpt.sh POSTROUTING - NAT Chain POSTROUTING (policy ACCEPT 1254 packets, 167219 bytes) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * eth0 20.20.20.4 0.0.0.0/0 to:95.75.75.104 MANGLE Chain PREROUTING (policy ACCEPT 27667 packets, 2716681 bytes) pkts bytes target prot opt in out source destination 252 21872 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 0 0 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 0.0.0.0:8080 mark 0x1/0x1 Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 254 21952 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK set 0x1 254 21952 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 In this case, SNAT is happening properly. But ACK is not happening as part of the three-way handshake. So the client hangs around till the timeout happens. Please find attached the sample-TPROXY server code with this. Am I missing any commands or configuration? TIA. Regards, Arun S. On 26/10/2007, Laszlo Attila Toth <panther@balabit.hu> wrote:
Arun S írta:
Oops!
Shall I go ahead with linux-2.6.23.tar.bz2 and tproxy4-2.6.23-200710090922.tar.bz2 ?
Yes... If you mean these two:
http://people.netfilter.org/hidden/tproxy/iptables-tproxy-200710091749.diff http://people.netfilter.org/hidden/tproxy/tproxy4-2.6.23-200710090922.tar.bz...
-- Panther
-- Regards, Arun S.
Hello, On 2007.10.30., at 8:13, Arun S wrote:
Hi Attila,
I have a problem with tproxy4 that I downloaded from the given links.
Scenario 2: Testing SNAT with TPROXY:
The following ip and iptable rules are added: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 8080
iptables -t nat -A POSTROUTING -o eth0 -s 20.20.20.4 -j SNAT --to 95.75.75.104
Output:
[root@Arun-FC6-SQUID ~]# ./listIpt.sh POSTROUTING - NAT Chain POSTROUTING (policy ACCEPT 1254 packets, 167219 bytes) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * eth0 20.20.20.4 0.0.0.0/0 to:95.75.75.104
MANGLE Chain PREROUTING (policy ACCEPT 27667 packets, 2716681 bytes) pkts bytes target prot opt in out source destination 252 21872 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 0 0 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 0.0.0.0:8080 mark 0x1/0x1 Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 254 21952 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK set 0x1 254 21952 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
In this case, SNAT is happening properly. But ACK is not happening as part of the three-way handshake. So the client hangs around till the timeout happens.
You didn't write what kind of TCP traffic doesn't work. If it comes from the LAN1 network and the destination port is 80, it will go to the TPROXY target to squid. All other traffic coming from the LAN1 is independent from the tproxy patches, also it should work. If the actual snat-ted traffic's local endpoint is the squid, it can bind to that IP address (to any IP if the TRANSPARENT sockopt is set).
Please find attached the sample-TPROXY server code with this.
That seems ok and it works in the first scenario. This is what I tested with netcat patched to use IP_TRANSPARENT socket option. But I didn't use SNAT because IP_TRANSPARENT lets the program bind to any IP address when it connects to any other server (this would be the server-side connection of the squid if the binding to foreign address is necessary). -- Attila
Hi, On 30/10/2007, Tóth László Attila <panther@elte.hu> wrote:
Hello,
On 2007.10.30., at 8:13, Arun S wrote:
Hi Attila,
I have a problem with tproxy4 that I downloaded from the given links.
Scenario 2: Testing SNAT with TPROXY:
The following ip and iptable rules are added: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -N DIVERT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 8080
iptables -t nat -A POSTROUTING -o eth0 -s 20.20.20.4 -j SNAT --to 95.75.75.104
Output:
[root@Arun-FC6-SQUID ~]# ./listIpt.sh POSTROUTING - NAT Chain POSTROUTING (policy ACCEPT 1254 packets, 167219 bytes) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * eth0 20.20.20.4 0.0.0.0/0 to:95.75.75.104
MANGLE Chain PREROUTING (policy ACCEPT 27667 packets, 2716681 bytes) pkts bytes target prot opt in out source destination 252 21872 DIVERT tcp -- * * 0.0.0.0/0 0.0.0.0/0 socket 0 0 TPROXY tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 TPROXY redirect 0.0.0.0:8080 mark 0x1/0x1 Chain DIVERT (1 references) pkts bytes target prot opt in out source destination 254 21952 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK set 0x1 254 21952 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
In this case, SNAT is happening properly. But ACK is not happening as part of the three-way handshake. So the client hangs around till the timeout happens.
You didn't write what kind of TCP traffic doesn't work. If it comes from the LAN1 network and the destination port is 80, it will go to the TPROXY target to squid. All other traffic coming from the LAN1 is independent from the tproxy patches, also it should work.
True. Traffic from LAN1 and dport 80 gets redirected to TPROXY server and as you said, all other traffic is independent of tproxy marks.
If the actual snat-ted traffic's local endpoint is the squid, it can bind to that IP address (to any IP if the TRANSPARENT sockopt is set).
Please find attached the sample-TPROXY server code with this.
That seems ok and it works in the first scenario. This is what I tested with netcat patched to use IP_TRANSPARENT socket option. But I didn't use SNAT because IP_TRANSPARENT lets the program bind to any IP address when it connects to any other server (this would be the server-side connection of the squid if the binding to foreign address is necessary).
That is fine. Since IP_TRANSPARENT lets the program to bind to any IP address, the application can be made to use any IP address as the source. But let us assume the following scenario: there are two outgoing WAN interfaces: eth0 and eth1. 1. Outgoing Traffic from eth0 should not be SNAT-ted. 2. Outgoing traffic from eth1 should be SNAT-ted. All WWW traffic gets marked, hits TPROXY redirect rule, and goes to TPROXY server. Case 1 is fine for TPROXY traffic and other traffic. But in Case 2, when SNAT happens, three-way handshake between TPROXY server and Web server is not successful. This issue is only with the Web traffic that is originated from TPROXY server (i.e., the server with IP_TRANSPARENT option set). Observation: 1. TPROXY server sends SYN packet with foreign source IP to WWW server 2. WWW server sends SYN-ACK to TPROXY server. 3. TPROXY server is not sending ACK to WWW server that leads to a half-open connection. Please let me know if you require more information.
-- Attila
-- Regards, Arun S.
Hello, On 2007.10.30., at 10:29, Arun S wrote:
That is fine. Since IP_TRANSPARENT lets the program to bind to any IP address, the application can be made to use any IP address as the source.
But let us assume the following scenario:
there are two outgoing WAN interfaces: eth0 and eth1.
1. Outgoing Traffic from eth0 should not be SNAT-ted. 2. Outgoing traffic from eth1 should be SNAT-ted.
All WWW traffic gets marked, hits TPROXY redirect rule, and goes to TPROXY server.
Case 1 is fine for TPROXY traffic and other traffic.
But in Case 2, when SNAT happens, three-way handshake between TPROXY server and Web server is not successful. This issue is only with the Web traffic that is originated from TPROXY server (i.e., the server with IP_TRANSPARENT option set).
Observation:
1. TPROXY server sends SYN packet with foreign source IP to WWW server
2. WWW server sends SYN-ACK to TPROXY server.
3. TPROXY server is not sending ACK to WWW server that leads to a half-open connection.
Ah, I see. I had the same problem when I used the other version of Tproxy4... In the other version I missed to check a condition (which is not important now), also the incoming tproxied packets didn't arrive to the socket that is specified by the TPROXY target. In this case the problem is similar to this one. The routing decision happens somewhere near the PREROUTING hook (I'd say at the end of the chain which may be modified by rules in this chain). First the mangle table is checked then the nat table, in both of them the PREROUTING chains, then the packet can go to the FORWARD or the INPUT chain if it is not dropped previously, depending on the routing decision. The latter one fails somehow. This is not a real problem in this case because it can be made in an other way. The "workaround" may be this one: - spoof.sin_addr.s_addr = client.sin_addr.s_addr; + spoof.sin_addr.s_addr = inet_addr ("95.75.75.104"); Hm, did you set the INPUT policy to ACCEPT the incoming connections? I ask it beacuse you didn't send the output of iptables -L. For instance the following is enough: (iptables -F) iptables -P INPUT DROP iptables -A INPUT -m mark --fwmark 1 -j ACCEPT -- Attila
On 30/10/2007, Tóth László Attila <panther@elte.hu> wrote:
Hello,
On 2007.10.30., at 10:29, Arun S wrote:
That is fine. Since IP_TRANSPARENT lets the program to bind to any IP address, the application can be made to use any IP address as the source.
But let us assume the following scenario:
there are two outgoing WAN interfaces: eth0 and eth1.
1. Outgoing Traffic from eth0 should not be SNAT-ted. 2. Outgoing traffic from eth1 should be SNAT-ted.
All WWW traffic gets marked, hits TPROXY redirect rule, and goes to TPROXY server.
Case 1 is fine for TPROXY traffic and other traffic.
But in Case 2, when SNAT happens, three-way handshake between TPROXY server and Web server is not successful. This issue is only with the Web traffic that is originated from TPROXY server (i.e., the server with IP_TRANSPARENT option set).
Observation:
1. TPROXY server sends SYN packet with foreign source IP to WWW server
2. WWW server sends SYN-ACK to TPROXY server.
3. TPROXY server is not sending ACK to WWW server that leads to a half-open connection.
Ah, I see. I had the same problem when I used the other version of Tproxy4...
In the other version I missed to check a condition (which is not important now), also the incoming tproxied packets didn't arrive to the socket that is specified by the TPROXY target. In this case the problem is similar to this one. The routing decision happens somewhere near the PREROUTING hook (I'd say at the end of the chain which may be modified by rules in this chain). First the mangle table is checked then the nat table, in both of them the PREROUTING chains, then the packet can go to the FORWARD or the INPUT chain if it is not dropped previously, depending on the routing decision. The latter one fails somehow. This is not a real problem in this case because it can be made in an other way.
The "workaround" may be this one:
- spoof.sin_addr.s_addr = client.sin_addr.s_addr; + spoof.sin_addr.s_addr = inet_addr ("95.75.75.104");
Yes. I already tested this out and as you said, it is fine :)
Hm, did you set the INPUT policy to ACCEPT the incoming connections? I ask it beacuse you didn't send the output of iptables -L.
For instance the following is enough: (iptables -F) iptables -P INPUT DROP iptables -A INPUT -m mark --fwmark 1 -j ACCEPT
Well... all my policies are set to ACCEPT. So I don't think this is causing trouble, fyi... [root@Arun-FC6-SQUID ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
-- Attila
-- Regards, Arun S.
On 2007.10.30., at 11:05, Arun S wrote:
On 30/10/2007, Tóth László Attila <panther@elte.hu> wrote:
Hello,
On 2007.10.30., at 10:29, Arun S wrote:
- spoof.sin_addr.s_addr = client.sin_addr.s_addr; + spoof.sin_addr.s_addr = inet_addr ("95.75.75.104");
Yes. I already tested this out and as you said, it is fine :)
Hm, did you set the INPUT policy to ACCEPT the incoming connections? I ask it beacuse you didn't send the output of iptables -L.
For instance the following is enough: (iptables -F) iptables -P INPUT DROP iptables -A INPUT -m mark --fwmark 1 -j ACCEPT
Well... all my policies are set to ACCEPT. So I don't think this is causing trouble,
Hm, it seems I'm right: the routing doesn't work if the SNAT is used. It requires some debugging (by me), I can do this only next week. -- Attila
Attila, FYI, routing doesn't happen only for packets with foreign source address. Thank you for the help :) On 30/10/2007, Tóth László Attila <panther@elte.hu> wrote:
On 2007.10.30., at 11:05, Arun S wrote:
On 30/10/2007, Tóth László Attila <panther@elte.hu> wrote:
Hello,
On 2007.10.30., at 10:29, Arun S wrote:
- spoof.sin_addr.s_addr = client.sin_addr.s_addr; + spoof.sin_addr.s_addr = inet_addr ("95.75.75.104");
Yes. I already tested this out and as you said, it is fine :)
Hm, did you set the INPUT policy to ACCEPT the incoming connections? I ask it beacuse you didn't send the output of iptables -L.
For instance the following is enough: (iptables -F) iptables -P INPUT DROP iptables -A INPUT -m mark --fwmark 1 -j ACCEPT
Well... all my policies are set to ACCEPT. So I don't think this is causing trouble,
Hm, it seems I'm right: the routing doesn't work if the SNAT is used. It requires some debugging (by me), I can do this only next week. -- Attila
-- Regards, Arun S.
On 2007.10.30., at 11:32, Arun S wrote:
Attila,
FYI, routing doesn't happen only for packets with foreign source address.
Thank you for the help :)
I mean: internally too - for which hooks, including socket lookup... I have another idea: please log every packets matching your test environment: source and destination port is 80 in two separate rules, propably with --tcp- options, in all chains of the mangle, nat and filter tables. The packets somewhere disappears. But the question is: where? -- Attila
Hi, On k, okt 30, 2007 at 02:59:51 +0530, Arun S wrote:
That seems ok and it works in the first scenario. This is what I tested with netcat patched to use IP_TRANSPARENT socket option. But I didn't use SNAT because IP_TRANSPARENT lets the program bind to any IP address when it connects to any other server (this would be the server-side connection of the squid if the binding to foreign address is necessary).
That is fine. Since IP_TRANSPARENT lets the program to bind to any IP address, the application can be made to use any IP address as the source.
But let us assume the following scenario:
there are two outgoing WAN interfaces: eth0 and eth1.
1. Outgoing Traffic from eth0 should not be SNAT-ted. 2. Outgoing traffic from eth1 should be SNAT-ted.
All WWW traffic gets marked, hits TPROXY redirect rule, and goes to TPROXY server.
Case 1 is fine for TPROXY traffic and other traffic.
But in Case 2, when SNAT happens, three-way handshake between TPROXY server and Web server is not successful. This issue is only with the Web traffic that is originated from TPROXY server (i.e., the server with IP_TRANSPARENT option set).
Observation:
1. TPROXY server sends SYN packet with foreign source IP to WWW server
2. WWW server sends SYN-ACK to TPROXY server.
3. TPROXY server is not sending ACK to WWW server that leads to a half-open connection.
Please let me know if you require more information.
This is probably a byproduct of the fact that PREROUTING/mangle is traversed before PREROUTING/nat. If you SNAT a TCP connection with non-local IP then the return packet on mangle will have the modified destination IP and thus the socket match won't find the socket. For now the only solution I see is modifying your SNAT rule so that connections initiated by the proxy won't be SNAT-ted and you do the translation _in_ the proxy. Of course a proper solution would be better on the long run. -- KOVACS Krisztian
On 2007.10.30., at 11:40, KOVACS Krisztian wrote:
Hi,
On k, okt 30, 2007 at 02:59:51 +0530, Arun S wrote:
That seems ok and it works in the first scenario. This is what I tested with netcat patched to use IP_TRANSPARENT socket option. But I didn't use SNAT because IP_TRANSPARENT lets the program bind to any IP address when it connects to any other server (this would be the server-side connection of the squid if the binding to foreign address is necessary).
That is fine. Since IP_TRANSPARENT lets the program to bind to any IP address, the application can be made to use any IP address as the source.
But let us assume the following scenario:
there are two outgoing WAN interfaces: eth0 and eth1.
1. Outgoing Traffic from eth0 should not be SNAT-ted. 2. Outgoing traffic from eth1 should be SNAT-ted.
All WWW traffic gets marked, hits TPROXY redirect rule, and goes to TPROXY server.
Case 1 is fine for TPROXY traffic and other traffic.
But in Case 2, when SNAT happens, three-way handshake between TPROXY server and Web server is not successful. This issue is only with the Web traffic that is originated from TPROXY server (i.e., the server with IP_TRANSPARENT option set).
Observation:
1. TPROXY server sends SYN packet with foreign source IP to WWW server
2. WWW server sends SYN-ACK to TPROXY server.
3. TPROXY server is not sending ACK to WWW server that leads to a half-open connection.
Please let me know if you require more information.
This is probably a byproduct of the fact that PREROUTING/mangle is traversed before PREROUTING/nat.
If you SNAT a TCP connection with non-local IP then the return packet on mangle will have the modified destination IP and thus the socket match won't find the socket.
Ops, I forgot the routing table numbered 100. If the socket match doesn't find the socket, it won't be marked to 1 also the packet's destination won't be handled as a local address this is why it fails: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 -- Attila
Okay. I will give a shot at it here. Regards, Arun S. On 30/10/2007, Tóth László Attila <panther@elte.hu> wrote:
On 2007.10.30., at 11:40, KOVACS Krisztian wrote:
Hi,
On k, okt 30, 2007 at 02:59:51 +0530, Arun S wrote:
That seems ok and it works in the first scenario. This is what I tested with netcat patched to use IP_TRANSPARENT socket option. But I didn't use SNAT because IP_TRANSPARENT lets the program bind to any IP address when it connects to any other server (this would be the server-side connection of the squid if the binding to foreign address is necessary).
That is fine. Since IP_TRANSPARENT lets the program to bind to any IP address, the application can be made to use any IP address as the source.
But let us assume the following scenario:
there are two outgoing WAN interfaces: eth0 and eth1.
1. Outgoing Traffic from eth0 should not be SNAT-ted. 2. Outgoing traffic from eth1 should be SNAT-ted.
All WWW traffic gets marked, hits TPROXY redirect rule, and goes to TPROXY server.
Case 1 is fine for TPROXY traffic and other traffic.
But in Case 2, when SNAT happens, three-way handshake between TPROXY server and Web server is not successful. This issue is only with the Web traffic that is originated from TPROXY server (i.e., the server with IP_TRANSPARENT option set).
Observation:
1. TPROXY server sends SYN packet with foreign source IP to WWW server
2. WWW server sends SYN-ACK to TPROXY server.
3. TPROXY server is not sending ACK to WWW server that leads to a half-open connection.
Please let me know if you require more information.
This is probably a byproduct of the fact that PREROUTING/mangle is traversed before PREROUTING/nat.
If you SNAT a TCP connection with non-local IP then the return packet on mangle will have the modified destination IP and thus the socket match won't find the socket.
Ops, I forgot the routing table numbered 100. If the socket match doesn't find the socket, it won't be marked to 1 also the packet's destination won't be handled as a local address this is why it fails: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
-- Attila
-- Regards, Arun S.
Hi Attila, Any updates on the SNAT issue with tproxy4 related to sockets? On 30/10/2007, Arun S <hi2arun@gmail.com> wrote:
Okay. I will give a shot at it here.
Regards, Arun S.
On 30/10/2007, Tóth László Attila <panther@elte.hu> wrote:
On 2007.10.30., at 11:40, KOVACS Krisztian wrote:
Hi,
On k, okt 30, 2007 at 02:59:51 +0530, Arun S wrote:
That seems ok and it works in the first scenario. This is what I tested with netcat patched to use IP_TRANSPARENT socket option. But I didn't use SNAT because IP_TRANSPARENT lets the program bind to any IP address when it connects to any other server (this would be the server-side connection of the squid if the binding to foreign address is necessary).
That is fine. Since IP_TRANSPARENT lets the program to bind to any IP address, the application can be made to use any IP address as the source.
But let us assume the following scenario:
there are two outgoing WAN interfaces: eth0 and eth1.
1. Outgoing Traffic from eth0 should not be SNAT-ted. 2. Outgoing traffic from eth1 should be SNAT-ted.
All WWW traffic gets marked, hits TPROXY redirect rule, and goes to TPROXY server.
Case 1 is fine for TPROXY traffic and other traffic.
But in Case 2, when SNAT happens, three-way handshake between TPROXY server and Web server is not successful. This issue is only with the Web traffic that is originated from TPROXY server (i.e., the server with IP_TRANSPARENT option set).
Observation:
1. TPROXY server sends SYN packet with foreign source IP to WWW server
2. WWW server sends SYN-ACK to TPROXY server.
3. TPROXY server is not sending ACK to WWW server that leads to a half-open connection.
Please let me know if you require more information.
This is probably a byproduct of the fact that PREROUTING/mangle is traversed before PREROUTING/nat.
If you SNAT a TCP connection with non-local IP then the return packet on mangle will have the modified destination IP and thus the socket match won't find the socket.
Ops, I forgot the routing table numbered 100. If the socket match doesn't find the socket, it won't be marked to 1 also the packet's destination won't be handled as a local address this is why it fails: ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100
-- Attila
-- Regards, Arun S.
-- Regards, Arun S.
Hi Arun, On Mon, Nov 19, 2007 at 07:04:14PM +0530, Arun S wrote:
Any updates on the SNAT issue with tproxy4 related to sockets?
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow. -- KOVACS Krisztian
On Mon, 2007-11-19 at 15:48 +0100, KOVACS Krisztian wrote:
Hi Arun,
On Mon, Nov 19, 2007 at 07:04:14PM +0530, Arun S wrote:
Any updates on the SNAT issue with tproxy4 related to sockets?
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly. -- Bazsi
Hi, On k, nov 20, 2007 at 11:33:53 +0100, Balazs Scheidler wrote:
On Mon, Nov 19, 2007 at 07:04:14PM +0530, Arun S wrote:
Any updates on the SNAT issue with tproxy4 related to sockets?
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options: * to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless); * to re-introduce the tproxy table and do the socket matching and marking in tproxy. The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment. The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution... -- KOVACS Krisztian
On Tue, 2007-11-20 at 12:17 +0100, KOVACS Krisztian wrote:
Hi,
On k, nov 20, 2007 at 11:33:53 +0100, Balazs Scheidler wrote:
On Mon, Nov 19, 2007 at 07:04:14PM +0530, Arun S wrote:
Any updates on the SNAT issue with tproxy4 related to sockets?
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options:
* to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless);
Yeah, but in that way the "socket" match would pull in the dependency on the NAT module unconditonally.
* to re-introduce the tproxy table and do the socket matching and marking in tproxy.
The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment.
The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution...
I see. -- Bazsi
Hi, On k, nov 20, 2007 at 12:23:25 +0100, Balazs Scheidler wrote:
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options:
* to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless);
Yeah, but in that way the "socket" match would pull in the dependency on the NAT module unconditonally.
Not necessarily: that part could be enclosed by #ifdef CONFIG_NF_NAT guards.
* to re-introduce the tproxy table and do the socket matching and marking in tproxy.
The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment.
The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution...
I see.
Erm, more feedback would be really reassuring... ;) -- KOVACS Krisztian
Hi, In the case of solution 2 (i.e, going for tproxy table and using sockref), maintaining the foreign address in conntrack for the whole session is mandatory. If the foreign address is deleted from conntrack, once a "confirmed" call from Conntrack is received, then it is difficult to handle mangling of packets in POSTROUTING chain based on foreign address. On 20/11/2007, KOVACS Krisztian <hidden@sch.bme.hu> wrote:
Hi,
On k, nov 20, 2007 at 12:23:25 +0100, Balazs Scheidler wrote:
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options:
* to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless);
Yeah, but in that way the "socket" match would pull in the dependency on the NAT module unconditonally.
Not necessarily: that part could be enclosed by #ifdef CONFIG_NF_NAT guards.
* to re-introduce the tproxy table and do the socket matching and marking in tproxy.
The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment.
The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution...
I see.
Erm, more feedback would be really reassuring... ;)
-- KOVACS Krisztian
-- Regards, Arun S.
In solution 2, instead of going for sockref and by making the foreign address persistent till the connection ends (using socket marking), this issue could be resolved. Please correct me if I am wrong. On 20/11/2007, Arun S <hi2arun@gmail.com> wrote:
Hi,
In the case of solution 2 (i.e, going for tproxy table and using sockref), maintaining the foreign address in conntrack for the whole session is mandatory.
If the foreign address is deleted from conntrack, once a "confirmed" call from Conntrack is received, then it is difficult to handle mangling of packets in POSTROUTING chain based on foreign address.
On 20/11/2007, KOVACS Krisztian <hidden@sch.bme.hu> wrote:
Hi,
On k, nov 20, 2007 at 12:23:25 +0100, Balazs Scheidler wrote:
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options:
* to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless);
Yeah, but in that way the "socket" match would pull in the dependency on the NAT module unconditonally.
Not necessarily: that part could be enclosed by #ifdef CONFIG_NF_NAT guards.
* to re-introduce the tproxy table and do the socket matching and marking in tproxy.
The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment.
The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution...
I see.
Erm, more feedback would be really reassuring... ;)
-- KOVACS Krisztian
-- Regards, Arun S.
-- Regards, Arun S.
On Tue, 2007-11-20 at 14:26 +0100, KOVACS Krisztian wrote:
Hi,
On k, nov 20, 2007 at 12:23:25 +0100, Balazs Scheidler wrote:
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options:
* to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless);
Yeah, but in that way the "socket" match would pull in the dependency on the NAT module unconditonally.
Not necessarily: that part could be enclosed by #ifdef CONFIG_NF_NAT guards.
I might be missing something, but if you are talking about compile time dependency: a kernel might contain both NAT _and_ tproxy in its configuration, e.g. the dependency in the socket match would be there. Most distribution kernels are like that. At runtime you'd pull in the NAT module, even if nothing else uses it, and even if the user does not have _any_ NAT rules. This is suboptimal.
* to re-introduce the tproxy table and do the socket matching and marking in tproxy.
The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment.
The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution...
I see.
Erm, more feedback would be really reassuring... ;)
Would you move the TPROXY target back to this table again? I was wondering if the name 'tproxy' is the best, can you see any other useful function of the table apart from tproxy? a table-to-be-consulted-after-nat :) hmm 'mangle_afternat' or postnat, or something? I'm not against naming it tproxy, but the first reason to drop the tproxy table was to avoid a tproxy specific table. -- Bazsi
Hi, On k, nov 20, 2007 at 02:45:59 +0100, Balazs Scheidler wrote:
On Tue, 2007-11-20 at 14:26 +0100, KOVACS Krisztian wrote:
Hi,
On k, nov 20, 2007 at 12:23:25 +0100, Balazs Scheidler wrote:
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options:
* to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless);
Yeah, but in that way the "socket" match would pull in the dependency on the NAT module unconditonally.
Not necessarily: that part could be enclosed by #ifdef CONFIG_NF_NAT guards.
I might be missing something, but if you are talking about compile time dependency: a kernel might contain both NAT _and_ tproxy in its configuration, e.g. the dependency in the socket match would be there. Most distribution kernels are like that.
At runtime you'd pull in the NAT module, even if nothing else uses it, and even if the user does not have _any_ NAT rules.
This is suboptimal.
I don't see why I'd force a dependency on NAT this way. To get the original address I only need the conntrack entry pointer (if we have one). And that's available even if we don't have NAT or conntrack loaded, it's just that either nfct is NULL or the NAT_DONE_* bits in the conntrack entry status field not set.
* to re-introduce the tproxy table and do the socket matching and marking in tproxy.
The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment.
The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution...
I see.
Erm, more feedback would be really reassuring... ;)
Would you move the TPROXY target back to this table again?
Well, I guess we don't have any other choice if we would like to support NAT...
I was wondering if the name 'tproxy' is the best, can you see any other useful function of the table apart from tproxy?
a table-to-be-consulted-after-nat :) hmm 'mangle_afternat' or postnat, or something?
I'm not against naming it tproxy, but the first reason to drop the tproxy table was to avoid a tproxy specific table.
That's a good point. Let's ask Patrick. -- KOVACS Krisztian
On Nov 20 2007 15:16, KOVACS Krisztian wrote:
I was wondering if the name 'tproxy' is the best, can you see any other useful function of the table apart from tproxy?
a table-to-be-consulted-after-nat :) hmm 'mangle_afternat' or postnat, or something?
I'm not against naming it tproxy, but the first reason to drop the tproxy table was to avoid a tproxy specific table.
That's a good point. Let's ask Patrick.
Ideally there is this supermassive plan of a number of people to refactor iptables one way or the other so that you do not /have/ to create a tproxy table in the first place ;-)
participants (8)
-
Arun S
-
Balazs Scheidler
-
Herlon Alcantara Matos
-
Jan Engelhardt
-
KOVACS Krisztian
-
Laszlo Attila Toth
-
Tóth László Attila
-
Tóth László Attila