Re: DNAT and local hosts

[Ray Leach <spoons@rchq.co.za>]

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

Pieter De Wit wrote:
> Thought so - the other way is to run portfwd and use it to forward the
> port "back to C1" - it would have helped if they had an input chain on
> -t nat :)
> 
> Thanks any ways 
> 
> -----Original Message-----
> From: Ray Leach [mailto:spoons@rchq.co.za] 
> Sent: 2007/05/08 08:05
> To: Pieter De Wit
> Cc: Jan Engelhardt; netfilter@lists.netfilter.org
> Subject: Re: DNAT and local hosts
> 
> Pieter De Wit wrote:
>> *BEEP* *BUZZ* I know - but it's for a closed source app that I need to
> 
>> do this - and it takes the address from the server, the protocol 
>> doesn't carry it it :)
>>
>>
>> -----Original Message-----
>> From: Jan Engelhardt [mailto:jengelh@linux01.gwdg.de]
>> Sent: Mon 2007/05/07 18:01
>> To: Pieter De Wit
>> Cc: netfilter@lists.netfilter.org
>> Subject: Re: DNAT and local hosts
>>  
>>
>> On May 7 2007 17:54, Pieter De Wit wrote:
>>> Now, all connections are routed out via FW:ppp0 and at NAT'ed. There 
>>> is a rule that allows connections to ppp0 on port 1234 and DNAT's 
>>> them to C1. When C2 makes a connection to 1.2.3.4:1234 it fails with 
>>> "Connection refused" since there is no "server" listening on the 
>>> firewall's ppp0,port 1234.
>> *BEEP* *BUZZ* *ERROR*. You have a direct connection between C1 and C2.
>>
>>
>> Jan
> 
> There is no routing between C1 and C2, so your firewall never sees the
> traffic between the 2.
> 
> Put C1 and C2 on two seperate physical networks and connect them through
> firewall to get routing to happen, then you can use iptables to do
> NATing between them.
> 
> Else put two interfaces into your firewall, give each interface an ip
> address in the same subnet, configure bridging between the two, put C1
> on the end of one interface and C2 on the other if, then look into
> ebtables.
> “This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp "
> 
> 
> 

INPUT on -t nat wouldn't help you here since the destination is not the 
firewall ...