Redirecting ports in a bridge

Redirecting ports in a bridge

[Javier Prieto Martínez]

Hi.
I have a linux appliance from Eneo Tech. 
(http://www.eneotecnologia.com/) with the following setup:

   (192.168.1.x)        
192.168.1.7                                                     ---- 
SERVER1 192.168.2.1
    [ LAN1 ] ----------- [ ROUTER ] ---------- [ APPLIANCE ] -------- [ 
LAN 2 ] --------|
                        192.168.2.7            192.168.2.140        
(192.168.2.x)       ---- SERVER2 192.168.2.2

The appliance has 4 ethernet cards, and a br0 bridge which includes all 
them. ETH2 is connected to the router, ETH3 is connected to LAN2, and 
BR0 has an IP address of LAN2.

Now, I want to redirect all HTTP traffic going to SERVER1, to the same 
port SERVER2.

I've tried the following rule:

    iptables -t nat -A PREROUTING -p tcp -d 192.168.2.1 --dport 80 
--to-destination 192.168.2.2:80 -j DNAT


The redirection seems to be working, as far as I've seen with tcpdump on 
SERVER2, but I'm not able to make a connection.

I have two suppositions:

    1) I have to SNAT the response. I've tried that rule:
    iptables -t nat -A POSTROUTING -p tcp --sport 80 -s 192.168.2.2 -d 
192.168.1.0/24 -j SNAT --to-source 192.168.2.1

    2) I have to use ebtables, as I'm using a bridge.

Any help? Thanks in advance :-)

Re: Redirecting ports in a bridge

[Jan Engelhardt]

On Friday 2008-04-18 11:27, Javier Prieto Martínez wrote:

> Hi.
> I have a linux appliance from Eneo Tech. (http://www.eneotecnologia.com/) with
> the following setup:
>
>  (192.168.1.x)        192.168.1.7
> ---- SERVER1 192.168.2.1
>   [ LAN1 ] ----------- [ ROUTER ] ---------- [ APPLIANCE ] -------- [ LAN 2 ]
> --------|
>                       192.168.2.7            192.168.2.140
> (192.168.2.x)       ---- SERVER2 192.168.2.2

your ascii art is broken

> The appliance has 4 ethernet cards, and a br0 bridge which includes all them.
> ETH2 is connected to the router, ETH3 is connected to LAN2, and BR0 has an IP
> address of LAN2.
>
> I've tried the following rule:
>
>   iptables -t nat -A PREROUTING -p tcp -d 192.168.2.1 --dport 80
> --to-destination 192.168.2.2:80 -j DNAT

IF you do bridge, then despite cabling being correct, you get
a NAT shortcircuit: jengelh.medozas.de/images/dnat-mistake.png

>   2) I have to use ebtables, as I'm using a bridge.

Not always.

Re: Redirecting ports in a bridge

[Javier Prieto Martínez]

Jan Engelhardt escribió:
> your ascii art is broken
>   
You're right. I'll try again:

* LAN1 (192.168.1.0/22)

[CLIENTS]--- [ROUTER (.7)]


* LAN2 (192.168.2.0/22)

[ROUTER (.7)] -- [APPLIANCE (.40)] -- SERVERS (.1&.2)

> IF you do bridge, then despite cabling being correct, you get
> a NAT shortcircuit: jengelh.medozas.de/images/dnat-mistake.png
>   
That's probably the problem, as far as I've seen with TCPDump. The point 
is, how can I fix that shortcut?

Thanks!

Re: Redirecting ports in a bridge

[Jan Engelhardt]

On Friday 2008-04-18 12:55, Javier Prieto Martínez wrote:
>>   
> You're right. I'll try again:
>
> * LAN1 (192.168.1.0/22)
>
> [CLIENTS]--- [ROUTER (.7)]
>
>
> * LAN2 (192.168.2.0/22)
>
> [ROUTER (.7)] -- [APPLIANCE (.40)] -- SERVERS (.1&.2)
>
>> IF you do bridge, then despite cabling being correct, you get
>> a NAT shortcircuit: jengelh.medozas.de/images/dnat-mistake.png
>>   
> That's probably the problem, as far as I've seen with TCPDump. The point is,
> how can I fix that shortcut?

You do not seem to need a bridge.

Re: Redirecting ports in a bridge

[Javier Prieto Martínez]

I need the bridge because the appliance is supposed to be totally 
trasparent to the network, as its main use is logging traffic.

It just has an IP address for administration purposes, but it doesn't 
really need it. Anyway, I can disable bridging as it's an appliance with 
a closed configuration.



Jan Engelhardt escribió:
> On Friday 2008-04-18 12:55, Javier Prieto Martínez wrote:
>   
>>>   
>>>       
>> You're right. I'll try again:
>>
>> * LAN1 (192.168.1.0/22)
>>
>> [CLIENTS]--- [ROUTER (.7)]
>>
>>
>> * LAN2 (192.168.2.0/22)
>>
>> [ROUTER (.7)] -- [APPLIANCE (.40)] -- SERVERS (.1&.2)
>>
>>     
>>> IF you do bridge, then despite cabling being correct, you get
>>> a NAT shortcircuit: jengelh.medozas.de/images/dnat-mistake.png
>>>   
>>>       
>> That's probably the problem, as far as I've seen with TCPDump. The point is,
>> how can I fix that shortcut?
>>     
>
> You do not seem to need a bridge.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>   

RE: Redirecting ports in a bridge

[Marc Cozzi]

Jan,

Can I ask what you are using for traffic logging
on your bridge? I am in need of fairly decent accounting
software for all traffic passing through the bridge.
HTTP, P2P, SSH etc. Bytes, time, IP# and so forth.

Regards,

  --marc


> -----Original Message-----
> From: netfilter-owner@vger.kernel.org 
> [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Javier 
> Prieto Martínez
> Sent: Friday, April 18, 2008 7:41 AM
> To: Jan Engelhardt; netfilter@vger.kernel.org
> Subject: Re: Redirecting ports in a bridge
> 
> I need the bridge because the appliance is supposed to be 
> totally trasparent to the network, as its main use is logging traffic.
> 
> It just has an IP address for administration purposes, but it 
> doesn't really need it. Anyway, I can disable bridging as 
> it's an appliance with a closed configuration.
> 
> 
> 
> Jan Engelhardt escribió:
> > On Friday 2008-04-18 12:55, Javier Prieto Martínez wrote:
> >   
> >>>   
> >>>       
> >> You're right. I'll try again:
> >>
> >> * LAN1 (192.168.1.0/22)
> >>
> >> [CLIENTS]--- [ROUTER (.7)]
> >>
> >>
> >> * LAN2 (192.168.2.0/22)
> >>
> >> [ROUTER (.7)] -- [APPLIANCE (.40)] -- SERVERS (.1&.2)
> >>
> >>     
> >>> IF you do bridge, then despite cabling being correct, you 
> get a NAT 
> >>> shortcircuit: jengelh.medozas.de/images/dnat-mistake.png
> >>>   
> >>>       
> >> That's probably the problem, as far as I've seen with TCPDump. The 
> >> point is, how can I fix that shortcut?
> >>     
> >
> > You do not seem to need a bridge.
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> netfilter" 
> > in the body of a message to majordomo@vger.kernel.org More 
> majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> >
> >   
> --
> To unsubscribe from this list: send the line "unsubscribe 
> netfilter" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
> http://vger.kernel.org/majordomo-info.html
> 

Re: Redirecting ports in a bridge

[Javier Prieto Martínez]

I'm using tcpdump for testing, but my appliance has it's own Java client 
for that purpose.


Marc Cozzi escribió:
> Jan,
>
> Can I ask what you are using for traffic logging
> on your bridge? I am in need of fairly decent accounting
> software for all traffic passing through the bridge.
> HTTP, P2P, SSH etc. Bytes, time, IP# and so forth.
>
> Regards,
>
>   --marc
>
>
>   
>> -----Original Message-----
>> From: netfilter-owner@vger.kernel.org 
>> [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Javier 
>> Prieto Martínez
>> Sent: Friday, April 18, 2008 7:41 AM
>> To: Jan Engelhardt; netfilter@vger.kernel.org
>> Subject: Re: Redirecting ports in a bridge
>>
>> I need the bridge because the appliance is supposed to be 
>> totally trasparent to the network, as its main use is logging traffic.
>>
>> It just has an IP address for administration purposes, but it 
>> doesn't really need it. Anyway, I can disable bridging as 
>> it's an appliance with a closed configuration.
>>
>>
>>
>> Jan Engelhardt escribió:
>>     
>>> On Friday 2008-04-18 12:55, Javier Prieto Martínez wrote:
>>>   
>>>       
>>>>>   
>>>>>       
>>>>>           
>>>> You're right. I'll try again:
>>>>
>>>> * LAN1 (192.168.1.0/22)
>>>>
>>>> [CLIENTS]--- [ROUTER (.7)]
>>>>
>>>>
>>>> * LAN2 (192.168.2.0/22)
>>>>
>>>> [ROUTER (.7)] -- [APPLIANCE (.40)] -- SERVERS (.1&.2)
>>>>
>>>>     
>>>>         
>>>>> IF you do bridge, then despite cabling being correct, you 
>>>>>           
>> get a NAT 
>>     
>>>>> shortcircuit: jengelh.medozas.de/images/dnat-mistake.png
>>>>>   
>>>>>       
>>>>>           
>>>> That's probably the problem, as far as I've seen with TCPDump. The 
>>>> point is, how can I fix that shortcut?
>>>>     
>>>>         
>>> You do not seem to need a bridge.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>>       
>> netfilter" 
>>     
>>> in the body of a message to majordomo@vger.kernel.org More 
>>>       
>> majordomo 
>>     
>>> info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>   
>>>       
>> --
>> To unsubscribe from this list: send the line "unsubscribe 
>> netfilter" in the body of a message to 
>> majordomo@vger.kernel.org More majordomo info at  
>> http://vger.kernel.org/majordomo-info.html
>>
>>     
>
>   

RE: Redirecting ports in a bridge

[Jan Engelhardt]

On Friday 2008-04-18 14:26, Marc Cozzi wrote:
>
>Can I ask what you are using for traffic logging
>on your bridge? I am in need of fairly decent accounting
>software for all traffic passing through the bridge.

I suppose LOG/ULOG/NFLOG for the typical things, and tcpdump
or a specially crafted logging target if you want the actual
layer-7 data.

Re: Redirecting ports in a bridge

[Grant Taylor]

On 04/18/08 06:41, Javier Prieto Martínez wrote:
> I need the bridge because the appliance is supposed to be totally 
> trasparent to the network, as its main use is logging traffic.

Ok, forgive me for asking.  Is this appliance multi-purpose in such that 
it is suppose to log and redirect traffic?

> It just has an IP address for administration purposes, but it doesn't 
> really need it. Anyway, I can disable bridging as it's an appliance 
> with a closed configuration.

*nod*



Grant. . . .

Re: Redirecting ports in a bridge

[Javier Prieto Martínez]

Grant Taylor escribió:

 > Ok, forgive me for asking. Is this appliance multi-purpose in such 
that it is suppose to log and redirect traffic?

Yes, It's multi-purpose: 
http://www.eneotecnologia.com/products_en.html?TB_iframe=true&height=510&width=800

    * *Firewall & QoS.-* High performance statefull firewall and quality
      of service.
    * *Web cache & content filter.-* Black and white list mode with LDAP
      or AD authentication.
    * *VPN.-*L2TP / IPSEC – X.509, NAT Traversal and high availability.
    * *IPS / IDS.-* Snort 2.6 based with hardware acceleration.
    * *Load balancing.-* LVS based – L3/4 classification, different
      algorithms.
    * *High availability.-* VRRP (Router mode) and STP (Bridge mode).
    * *Malware.-* Antivirus (ClamAV, Kaspersky), antispam (DSPAM,
      Mailshell), antispyware (Kaspersky, PCTools or Sunbelt) with
      hardware acceleration.
    * *NetFlow probe.-* NetFlow v5/9 Probe.


We use it in bridge mode, mainly for traffic logging, and sometimes for 
packet filtering.


 > As Jan Engelhardt has pointed out so well, you are very likely 
dealing with (what I call)
 > a "TCP Triangle". If there is not something else in the mix doing 
source NATing, you will
 > need to do something else to avoid the "TCP Triangle". There are many 
different options
 > available, one of which is the SNATing like you are referring to 
(though I would be careful
 > on selecting the packets to SNAT). Another would be to have your 
clients connect to IPs on
 > LAN 1 that are bound to the router that is DNATing traffic to LAN 2 
and then unDNATing the
 > replies. You could also have duplicate IPs bound on server 1 and 
server 2 and use some
 > clustering techniques to alter which MAC address / server the 
packet(s) go to, thus
 > allowing both servers to answer with the proper IP.

I still want the bridge to be totally transparent, and I don't want to 
mess with the real IPs, as I don't want the probe to be a single point 
of failure. In fact, it's network cards still work as a bridge when the 
machine is down.

I suppose I should use SNAT, then, as you've stated, but it doesn't seem 
to work properly. I'm trying that:

# iptables -t nat -A PREROUTING -p tcp -d 192.168.2.1 --dport 80 --to-destination 192.168.2.2:80 -j DNAT
# iptables -t nat -A POSTROUTING -p tcp --sport 80 -s 192.168.2.2 -d 192.168.1.0/24 -j SNAT --to-source 192.168.2.1

Re: Redirecting ports in a bridge

[Grant Taylor]

On 4/21/2008 1:55 AM, Javier Prieto Martínez wrote:
> Yes, It's multi-purpose: 
> http://www.eneotecnologia.com/products_en.html?TB_iframe=true&height=510&width=800
> - Firewall & QoS. High performance statefull firewall and quality of 
> service.
> - Web cache & content filter. Black and white list mode with LDAP or 
> AD authentication.
> - VPN. L2TP / IPSEC – X.509, NAT Traversal and high availability. 
> - IPS / IDS. Snort 2.6 based with hardware acceleration.
> - Load balancing. LVS based – L3/4 classification, different 
> algorithms.
> - High availability. VRRP (Router mode) and STP (Bridge mode).
> - Malware. Antivirus (ClamAV, Kaspersky), antispam (DSPAM, 
> Mailshell), antispyware (Kaspersky, PCTools or Sunbelt) with hardware 
> acceleration.
> - NetFlow probe. NetFlow v5/9 Probe.

*nod*

> We use it in bridge mode, mainly for traffic logging, and sometimes 
> for packet filtering.

Ok, to me logging is recording information and filtering is either 
allowing traffic to pass or not.  Based on your original post it sounds 
like you are wanting to do some re-direction of traffic too.  Is this 
correct?

> I still want the bridge to be totally transparent, and I don't want 
> to mess with the real IPs, as I don't want the probe to be a single 
> point of failure. In fact, it's network cards still work as a bridge 
> when the machine is down.

The bridge can not be totally transparent and change things at the same 
time.  If you are having the bridge change things, the network will 
operate differently with it in verses out of service.  Please clarify 
what you are wanting.

> I suppose I should use SNAT, then, as you've stated, but it doesn't 
> seem to work properly. I'm trying that:
> 
> # iptables -t nat -A PREROUTING -p tcp -d 192.168.2.1 --dport 80 
> --to-destination 192.168.2.2:80 -j DNAT
> # iptables -t nat -A POSTROUTING -p tcp --sport 80 -s 192.168.2.2 -d 
> 192.168.1.0/24 -j SNAT --to-source 192.168.2.1


Remember that IPTables operates on layer 3 and EBTables operates on 
layer 2.  So unless you have your kernel configured to do such, IPTables 
will not see layer 2 traffic.  So, either you need to use EBTables 
(preferred in my opinion) or you need to configure your kernel so that 
IPTables sees layer 2 traffic.



Grant. . . .

Re: Redirecting ports in a bridge

[Javier Prieto Martínez]

> Ok, to me logging is recording information and filtering is either 
> allowing traffic to pass or not.  Based on your original post it 
> sounds like you are wanting to do some re-direction of traffic too.  
> Is this correct?

Yes. We are logging and filtering right now, but we want to redirect 
traffic too.

> The bridge can not be totally transparent and change things at the 
> same time.  If you are having the bridge change things, the network 
> will operate differently with it in verses out of service.  Please 
> clarify what you are wanting.
The point is we want the bridge to be transparent except for one 
particular redirection we want to do :-)

> Remember that IPTables operates on layer 3 and EBTables operates on 
> layer 2.  So unless you have your kernel configured to do such, 
> IPTables will not see layer 2 traffic.  So, either you need to use 
> EBTables (preferred in my opinion) or you need to configure your 
> kernel so that IPTables sees layer 2 traffic.

Thanks for the advice. I'll try with EBTables, then.

Regards.
    Javier

Re: Redirecting ports in a bridge

[Grant Taylor]

On 04/22/08 01:15, Javier Prieto Martínez wrote:
> Yes. We are logging and filtering right now, but we want to redirect 
> traffic too.

*nod*

> The point is we want the bridge to be transparent except for one 
> particular redirection we want to do :-)

*nod*

> Thanks for the advice. I'll try with EBTables, then.

*nod*

Except for possibly some syntactical change your rules should be very 
similar and operate in the same fashion.

Based on your previous statement "I don't want to mess with the real 
IPs" it sounds like you don't even want to change source / destination 
IPs of the traffic going to the back end system.  Am I understanding you 
correctly that you indeed want to not alter the source and / or 
destination IP?  If this is the case, be aware that you do not want to 
NAT the IP and that you will be down to NATing the MAC address (which 
can be done but is another discussion) as the frame is passing through 
the bridge.

I guess I should ask:

+---+         +---+   +---+   +---+
| C +-- - - --+ R +---+ A +---+ S |
+---+         +---+   +---+   +---+

Presuming that C is the client, R is the router, A is the appliance, and 
S is one or more of the servers, do you want S to see the source and 
destination IP that the client connected to?  Or is it ok for the 
appliance to munge the source and / or destination IP (as seen by the 
server) in the process of redirecting to the server?



Grant. . . .

Re: Redirecting ports in a bridge

[Javier Prieto Martínez]

>> Thanks for the advice. I'll try with EBTables, then.
>
> *nod*
>
> Except for possibly some syntactical change your rules should be very 
> similar and operate in the same fashion.
>
> Based on your previous statement "I don't want to mess with the real 
> IPs" it sounds like you don't even want to change source / destination 
> IPs of the traffic going to the back end system.  Am I understanding 
> you correctly that you indeed want to not alter the source and / or 
> destination IP?  If this is the case, be aware that you do not want to 
> NAT the IP and that you will be down to NATing the MAC address (which 
> can be done but is another discussion) as the frame is passing through 
> the bridge.
>
> I guess I should ask:
>
> +---+         +---+   +---+   +---+
> | C +-- - - --+ R +---+ A +---+ S |
> +---+         +---+   +---+   +---+
>
> Presuming that C is the client, R is the router, A is the appliance, 
> and S is one or more of the servers, do you want S to see the source 
> and destination IP that the client connected to?  Or is it ok for the 
> appliance to munge the source and / or destination IP (as seen by the 
> server) in the process of redirecting to the server?

Well.. I don't speak English very well, so it's easy to misunderstand my 
posts :-)

In your graph, "S" is my LAN with my all my servers and local 
workstations. When I say that "I don't want to mess with the real IPs", 
I mean I don't want to make any change within my LAN.

The point of the redirection is that, when I need to make a change in 
one of my servers, I'd like my appliance to redirect all the traffic 
coming from the extranet ("C") to another server. For example, if I have 
to stop the web server while upgrading, I'd like all the traffic coming 
from outside to reach another web server with a catched version of my 
web page.

The proccess should be something like that:

* C starts a connection to S1, port 80
* R routes that packet to my LAN
* A captures that packet, and changes the destintation to S2, port 80
* S2 generates a response to C
* A captures that packet, and changes its source to S1, port 80
* R routes that packet to the outside network
* C gets a packet from S1, port 80

I'm making some tests with EBTables in my lab enviroment.
I'll tell you the results.

Thanks a lot.

Re: Redirecting ports in a bridge

[Grant Taylor]

On 04/22/08 10:10, Javier Prieto Martínez wrote:
> Well.. I don't speak English very well, so it's easy to misunderstand my 
> posts :-)

That's ok.  You are doing just fine.  :)

> In your graph, "S" is my LAN with my all my servers and local 
> workstations. When I say that "I don't want to mess with the real IPs", 
> I mean I don't want to make any change within my LAN.

*nod*

Just to make sure that I understand you correctly, you do not want to 
have to re-configure IP addresses on servers when you add or remove the 
appliance but you do not care if a given server sees the traffic as 
being to its self rather than the original address.  I.e.

C -> S1 (client sends traffic)
C -> S1 (router routes traffic)
C -> S1 (appliance receives traffic)
C -> S2 (and changes it to S2      )
C -> S2 (server 2 receives traffic)
S2 -> C (server 2 replies to traffic)
S2 -> C (appliance receives traffic)
S1 -> C (and changes it to S1      )
S1 -> C (router routes traffic)
S1 -> C (client receives traffic)

The key point is that S2 sees the traffic as being to (destination IP) 
its self, rather than to S1.

If this is ok with you, then DNATing / SNATing will work just fine.

> The point of the redirection is that, when I need to make a change in 
> one of my servers, I'd like my appliance to redirect all the traffic 
> coming from the extranet ("C") to another server. For example, if I have 
> to stop the web server while upgrading, I'd like all the traffic coming 
> from outside to reach another web server with a catched version of my 
> web page.

*nod*

> The proccess should be something like that:
> 
> * C starts a connection to S1, port 80
> * R routes that packet to my LAN
> * A captures that packet, and changes the destintation to S2, port 80
> * S2 generates a response to C
> * A captures that packet, and changes its source to S1, port 80
> * R routes that packet to the outside network
> * C gets a packet from S1, port 80

*nod*

> I'm making some tests with EBTables in my lab enviroment. 
> I'll tell you the results.

Ok.  Let me know if you need any thing else.

Remember that you will need to DNAT the inbound traffic and SNAT the 
outbound traffic too.

Also, if you are redirecting the traffic (originally to the downed 
server) to another up and functioning server, you have to be careful not 
to interfere with the other servers normally functioning traffic.

You can very simply write an EBTables rule to SNAT the traffic as it 
passes through the appliance.  However you have to make sure that you 
only SNAT the traffic that was originally DNATed and not all the traffic 
from S2.

> Thanks a lot.

You are welcome.



Grant. . . .

Re: Redirecting ports in a bridge

[Jan Engelhardt]

On Friday 2008-04-18 13:41, Javier Prieto Martínez wrote:

> I need the bridge because the appliance is supposed to be totally
> trasparent to the network, as its main use is logging traffic.

Often layer-2 transparency is not needed, but what do I know.
If you just log layer-3 (IP addrs) and up without caring about
MAC addresses, make a standard routing setup, i.e.
192.168.1.0/22 on eth0, 192.168.2.0/22 on eth1, and
enable forwarding; kinda like that.
And let hosts use 192.168.1.1/192.168.2.1 as a default gw
(as they already should do).

Re: Redirecting ports in a bridge

[Grant Taylor]

On 04/23/08 10:24, Jan Engelhardt wrote:
> Often layer-2 transparency is not needed, but what do I know. If you 
> just log layer-3 (IP addrs) and up without caring about MAC 
> addresses, make a standard routing setup, i.e. 192.168.1.0/22 on 
> eth0, 192.168.2.0/22 on eth1, and enable forwarding; kinda like that. 
> And let hosts use 192.168.1.1/192.168.2.1 as a default gw (as they 
> already should do).

If it was not for the fact that the OP wanted layer 3 transparency, I 
would agree with you.  However the desire to insert this between a 
router and one or more systems with out changing the IP addressing 
necessitates the use of layer 2 technology, i.e. bridging.



Grant. . . .

Re: Redirecting ports in a bridge

[Jan Engelhardt]

On Wednesday 2008-04-23 19:16, Grant Taylor wrote:

> On 04/23/08 10:24, Jan Engelhardt wrote:
>> Often layer-2 transparency is not needed, but what do I know. If you just log
>> layer-3 (IP addrs) and up without caring about MAC addresses, make a standard
>> routing setup, i.e. 192.168.1.0/22 on eth0, 192.168.2.0/22 on eth1, and
>> enable forwarding; kinda like that. And let hosts use 192.168.1.1/192.168.2.1
>> as a default gw (as they already should do).
>
> If it was not for the fact that the OP wanted layer 3 transparency, I would
> agree with you.  However the desire to insert this between a router and one or
> more systems with out changing the IP addressing necessitates the use of layer
> 2 technology, i.e. bridging.

Well what routes do clients have at the moment?

Re: Redirecting ports in a bridge

[Grant Taylor]

On 04/23/08 13:48, Jan Engelhardt wrote:
> Well what routes do clients have at the moment?

Clients will use their ISPs to cross the internet to the router in 
question to get to the server.  Conversely the servers will use said 
router to get back out to the world.

It sounds like presently clients will come in from the internet in to 
the router then on to the servers.  This set up is (apparently) up and 
running as it is.  The OP is wanting to put the appliance in between the 
router and the servers with out having to re-configure any IP addresses 
any where.



Grant. . . .

Re: Redirecting ports in a bridge

[Javier Prieto Martínez]

Exactly!

I'm still learning the basics in EBTables, BTW... O:-)


Grant Taylor escribió:
> On 04/23/08 13:48, Jan Engelhardt wrote:
>> Well what routes do clients have at the moment?
>
> Clients will use their ISPs to cross the internet to the router in 
> question to get to the server.  Conversely the servers will use said 
> router to get back out to the world.
>
> It sounds like presently clients will come in from the internet in to 
> the router then on to the servers.  This set up is (apparently) up and 
> running as it is.  The OP is wanting to put the appliance in between 
> the router and the servers with out having to re-configure any IP 
> addresses any where.
>
>
>
> Grant. . . .
> -- 
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Redirecting ports in a bridge

[Grant Taylor]

On 04/18/08 05:35, Jan Engelhardt wrote:
> IF you do bridge, then despite cabling being correct, you get a NAT 
> shortcircuit: jengelh.medozas.de/images/dnat-mistake.png

Jan, *VERY* nicely done depiction of the problem.  That is what I 
usually refer as a "TCP Triangle".



Grant. . . .

Re: Redirecting ports in a bridge

[Grant Taylor]

On 04/18/08 04:27, Javier Prieto Martínez wrote:
> 1) I have to SNAT the response. I've tried that rule:  iptables -t 
> nat -A POSTROUTING -p tcp --sport 80 -s 192.168.2.2 -d 192.168.1.0/24 
> -j SNAT --to-source 192.168.2.1

As Jan Engelhardt has pointed out so well, you are very likely dealing 
with (what I call) a "TCP Triangle".  If there is not something else in 
the mix doing source NATing, you will need to do something else to avoid 
the "TCP Triangle".  There are many different options available, one of 
which is the SNATing like you are referring to (though I would be 
careful on selecting the packets to SNAT).  Another would be to have 
your clients connect to IPs on LAN 1 that are bound to the router that 
is DNATing traffic to LAN 2 and then unDNATing the replies.  You could 
also have duplicate IPs bound on server 1 and server 2 and use some 
clustering techniques to alter which MAC address / server the packet(s) 
go to, thus allowing both servers to answer with the proper IP.

> 2) I have to use ebtables, as I'm using a bridge.

I would suggest that you use EBTables seeing as how you are bridging.  I 
think things will be easier to maintain and you will be using a simpler 
operation.



Grant. . . .