Forward internal packets as though they're external

Forward internal packets as though they're external

[Jon Heese]

List,

I have a seemingly simple situation here that I have yet to find a 
straightforward answer to, so here goes.  I have my router/firewall 
running iptables:

eth0 - 65.9.134.4
eth1 - 192.168.0.1

Then, say an internal machine, "castor":

eth0 - 192.168.0.100

I'm running a BitTorrent tracker on castor's TCP port 6969, and I'm 
using iptables to forward traffic coming in router's eth0's port 6969 to 
castor's 6969 (nat table, PREROUTING chain).  No problem coming in from 
outside.

The problem arises when I want to connect to castor's BitTorrent tracker 
from another machine behind the router (on the 192.168.0.0/24 subnet). 
It's matching the INPUT rule and sending the packet directly to router's 
port 6969, instead of following the FORWARD rule to castor's 6969, and 
while this makes sense to me, I don't want it to do it.

So, the simple solution, I say to myself, is to tell iptables to take 
all packets with destination address of 65.9.134.4 and source address of 
192.168.0.0/24 and dport 6969 to go to castor's 6969.  In English I 
think I have it fine.  Finding the right syntax/logic in iptablesish is 
where I get tripped up.  I can match the rule fine, I just don't know 
what action/jump I need to specify to make it redirect.

The rule is:

/sbin/iptables -A INPUT -d 65.9.134.4 -s 192.168.0.0/24 -p tcp --dport 6969

And if I add "-j DROP" or "-j ACCEPT", I get the appropriate action in 
my testing situation.  Now, the question:

What do I have to specify after the above rule definition to either a) 
get iptables to redirect this packet to my existing nat/PREROUTING chain 
(which may not be possible), or b) forward it directly to a specified 
IP:port?

If you need any more specifics or code or if I posted this to the wrong 
list, just let me know.  Thanks in advance.

Regards,
Jon Heese

Re: Forward internal packets as though they're external

[Buddy wu]

Try "/sbin/iptables -A INPUT -d 65.9.134.4 -s 192.168.0.0/24 -p tcp
--dport 6969 -j DNAT 192.168.0.100:6969"
It maybe work, I don't ensure

2005/10/27, Jon Heese <netfilter@jonheese.com>:
> List,
>
> I have a seemingly simple situation here that I have yet to find a
> straightforward answer to, so here goes.  I have my router/firewall
> running iptables:
>
> eth0 - 65.9.134.4
> eth1 - 192.168.0.1
>
> Then, say an internal machine, "castor":
>
> eth0 - 192.168.0.100
>
> I'm running a BitTorrent tracker on castor's TCP port 6969, and I'm
> using iptables to forward traffic coming in router's eth0's port 6969 to
> castor's 6969 (nat table, PREROUTING chain).  No problem coming in from
> outside.
>
> The problem arises when I want to connect to castor's BitTorrent tracker
> from another machine behind the router (on the 192.168.0.0/24 subnet).
> It's matching the INPUT rule and sending the packet directly to router's
> port 6969, instead of following the FORWARD rule to castor's 6969, and
> while this makes sense to me, I don't want it to do it.
>
> So, the simple solution, I say to myself, is to tell iptables to take
> all packets with destination address of 65.9.134.4 and source address of
> 192.168.0.0/24 and dport 6969 to go to castor's 6969.  In English I
> think I have it fine.  Finding the right syntax/logic in iptablesish is
> where I get tripped up.  I can match the rule fine, I just don't know
> what action/jump I need to specify to make it redirect.
>
> The rule is:
>
> /sbin/iptables -A INPUT -d 65.9.134.4 -s 192.168.0.0/24 -p tcp --dport 6969
>
> And if I add "-j DROP" or "-j ACCEPT", I get the appropriate action in
> my testing situation.  Now, the question:
>
> What do I have to specify after the above rule definition to either a)
> get iptables to redirect this packet to my existing nat/PREROUTING chain
> (which may not be possible), or b) forward it directly to a specified
> IP:port?
>
> If you need any more specifics or code or if I posted this to the wrong
> list, just let me know.  Thanks in advance.
>
> Regards,
> Jon Heese
>
>

Re: Forward internal packets as though they're external

[/dev/rob0]

On Wednesday 2005-October-26 23:04, Jon Heese wrote:
> straightforward answer to, so here goes.  I have my router/firewall
> running iptables:

Just an aside, FYI, "running iptables" is an inaccurate description. 
iptables(8) is not a daemon process, it merely manipulates netfilter 
rules in the kernel.

> eth0 - 65.9.134.4
> eth1 - 192.168.0.1
>
> Then, say an internal machine, "castor":
>
> eth0 - 192.168.0.100
>
> I'm running a BitTorrent tracker on castor's TCP port 6969, and I'm
> using iptables to forward traffic coming in router's eth0's port 6969
> to castor's 6969 (nat table, PREROUTING chain).  No problem coming in
> from outside.
>
> The problem arises when I want to connect to castor's BitTorrent
> tracker from another machine behind the router (on the 192.168.0.0/24

What is the rule you're using? If as above you're only DNAT'ing from 
eth0, you're not going to match anything coming in on eth1!

> subnet). It's matching the INPUT rule and sending the packet directly
> to router's port 6969, instead of following the FORWARD rule to
> castor's 6969, and while this makes sense to me, I don't want it to
> do it.
>
> So, the simple solution, I say to myself, is to tell iptables to take
> all packets with destination address of 65.9.134.4 and source address
> of 192.168.0.0/24 and dport 6969 to go to castor's 6969.  In English
> I think I have it fine.  Finding the right syntax/logic in

Right.

> iptablesish is where I get tripped up.  I can match the rule fine, I
> just don't know what action/jump I need to specify to make it
> redirect.
>
> The rule is:
>
> /sbin/iptables -A INPUT -d 65.9.134.4 -s 192.168.0.0/24 -p tcp
> --dport 6969

You can't do DNAT in the filter table, ...

> And if I add "-j DROP" or "-j ACCEPT", I get the appropriate action
> in my testing situation.  Now, the question:

... and you can't DNAT with a DROP or ACCEPT rule.

> What do I have to specify after the above rule definition to either
> a) get iptables to redirect this packet to my existing nat/PREROUTING
> chain (which may not be possible), or b) forward it directly to a

Change your DNAT rule to match all the packets you want to match:

iptables -vt nat -A PREROUTING -d 65.9.134.4 -p tcp --dport 6969 \
    -j DNAT --to 192.168.0.100

Although the idea of using BitTorrent over a local network seems quite 
odd to me ... :)
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Forward internal packets as though they're external

[Jon Heese]

Nope, that's the first thing I tried.  From what I can tell, the DNAT 
jump target is not valid in the INPUT chain (which makes sense).

Regards,
Jon Heese

Buddy wu wrote:
> Try "/sbin/iptables -A INPUT -d 65.9.134.4 -s 192.168.0.0/24 -p tcp
> --dport 6969 -j DNAT 192.168.0.100:6969"
> It maybe work, I don't ensure
> 
> 2005/10/27, Jon Heese <netfilter@jonheese.com>:
> 
>>List,
>>
>>I have a seemingly simple situation here that I have yet to find a
>>straightforward answer to, so here goes.  I have my router/firewall
>>running iptables:
>>
>>eth0 - 65.9.134.4
>>eth1 - 192.168.0.1
>>
>>Then, say an internal machine, "castor":
>>
>>eth0 - 192.168.0.100
>>
>>I'm running a BitTorrent tracker on castor's TCP port 6969, and I'm
>>using iptables to forward traffic coming in router's eth0's port 6969 to
>>castor's 6969 (nat table, PREROUTING chain).  No problem coming in from
>>outside.
>>
>>The problem arises when I want to connect to castor's BitTorrent tracker
>>from another machine behind the router (on the 192.168.0.0/24 subnet).
>>It's matching the INPUT rule and sending the packet directly to router's
>>port 6969, instead of following the FORWARD rule to castor's 6969, and
>>while this makes sense to me, I don't want it to do it.
>>
>>So, the simple solution, I say to myself, is to tell iptables to take
>>all packets with destination address of 65.9.134.4 and source address of
>>192.168.0.0/24 and dport 6969 to go to castor's 6969.  In English I
>>think I have it fine.  Finding the right syntax/logic in iptablesish is
>>where I get tripped up.  I can match the rule fine, I just don't know
>>what action/jump I need to specify to make it redirect.
>>
>>The rule is:
>>
>>/sbin/iptables -A INPUT -d 65.9.134.4 -s 192.168.0.0/24 -p tcp --dport 6969
>>
>>And if I add "-j DROP" or "-j ACCEPT", I get the appropriate action in
>>my testing situation.  Now, the question:
>>
>>What do I have to specify after the above rule definition to either a)
>>get iptables to redirect this packet to my existing nat/PREROUTING chain
>>(which may not be possible), or b) forward it directly to a specified
>>IP:port?
>>
>>If you need any more specifics or code or if I posted this to the wrong
>>list, just let me know.  Thanks in advance.
>>
>>Regards,
>>Jon Heese
>>
>>

Re: Forward internal packets as though they're external

[Jon Heese]

/dev/rob0 wrote:
> On Wednesday 2005-October-26 23:04, Jon Heese wrote:
> 
>>straightforward answer to, so here goes.  I have my router/firewall
>>running iptables:
> 
> 
> Just an aside, FYI, "running iptables" is an inaccurate description. 
> iptables(8) is not a daemon process, it merely manipulates netfilter 
> rules in the kernel.

Okay, point taken.

> 
>>eth0 - 65.9.134.4
>>eth1 - 192.168.0.1
>>
>>Then, say an internal machine, "castor":
>>
>>eth0 - 192.168.0.100
>>
>>I'm running a BitTorrent tracker on castor's TCP port 6969, and I'm
>>using iptables to forward traffic coming in router's eth0's port 6969
>>to castor's 6969 (nat table, PREROUTING chain).  No problem coming in
>>from outside.
>>
>>The problem arises when I want to connect to castor's BitTorrent
>>tracker from another machine behind the router (on the 192.168.0.0/24
> 
> 
> What is the rule you're using? If as above you're only DNAT'ing from 
> eth0, you're not going to match anything coming in on eth1!
> 

Yes, I realize that.  Hence my question.  I was just giving some 
background.  See last sentence in the next paragraph.

> 
>>subnet). It's matching the INPUT rule and sending the packet directly
>>to router's port 6969, instead of following the FORWARD rule to
>>castor's 6969, and while this makes sense to me, I don't want it to
>>do it.
>>
>>So, the simple solution, I say to myself, is to tell iptables to take
>>all packets with destination address of 65.9.134.4 and source address
>>of 192.168.0.0/24 and dport 6969 to go to castor's 6969.  In English
>>I think I have it fine.  Finding the right syntax/logic in
> 
> 
> Right.
> 
> 
>>iptablesish is where I get tripped up.  I can match the rule fine, I
>>just don't know what action/jump I need to specify to make it
>>redirect.
>>
>>The rule is:
>>
>>/sbin/iptables -A INPUT -d 65.9.134.4 -s 192.168.0.0/24 -p tcp
>>--dport 6969
> 
> 
> You can't do DNAT in the filter table, ...

The problem is that I *need* to do something in the INPUT chain in order 
to catch these packets (or at least it seems I do)...

> 
>>And if I add "-j DROP" or "-j ACCEPT", I get the appropriate action
>>in my testing situation.  Now, the question:
> 
> 
> ... and you can't DNAT with a DROP or ACCEPT rule.
> 

Well, I was in the INPUT chain and it was only for testing to make sure 
I was matching the right situation.  When I jumped to DROP, the packets 
matching the rule would drop, and when I jumped to ACCEPT, the packets 
were allowed (eg. if I left the --dport out, all packets to the external 
address were dropped/accepted based on the target I specified).

> 
>>What do I have to specify after the above rule definition to either
>>a) get iptables to redirect this packet to my existing nat/PREROUTING
>>chain (which may not be possible), or b) forward it directly to a
> 
> 
> Change your DNAT rule to match all the packets you want to match:
> 
> iptables -vt nat -A PREROUTING -d 65.9.134.4 -p tcp --dport 6969 \
>     -j DNAT --to 192.168.0.100

Except for the --verbose, that's exactly what I'm already doing to DNAT 
everything from the outside through to castor's 6969.  This rule does 
not seem to be catching traffic from the inside.  Do I have to do 
something special to get internal traffic into the PREROUTING chain?  Or 
maybe I'm doing something already that keeps it from getting to it?

> 
> Although the idea of using BitTorrent over a local network seems quite 
> odd to me ... :)

The BitTorrent *tracker* is on the same local network.  The clients/data 
are across the internet.  =)

Regards,
Jon Heese

Re: Forward internal packets as though they're external

[/dev/rob0]

On Thursday 2005-October-27 08:07, Jon Heese wrote:
> > Change your DNAT rule to match all the packets you want to match:
> >
> > iptables -vt nat -A PREROUTING -d 65.9.134.4 -p tcp --dport 6969 \
> >     -j DNAT --to 192.168.0.100
>
> Except for the --verbose, that's exactly what I'm already doing to
> DNAT everything from the outside through to castor's 6969.  This rule
> does not seem to be catching traffic from the inside.  Do I have to
> do something special to get internal traffic into the PREROUTING

After I sent this (and went to bed :) ) I realised what must be 
happening: it's getting the original packet there, but replies are 
going direct to the IP of the originator.

Suppose 192.168.0.129 connects to 65.9.134.4:6969 ... the router passes 
it faithfully on to 192.168.0.100. Now 192.168.0.100 has a packet from 
192.168.0.129, and it won't send the reply to 65.9.134.4. The client at 
192.168.0.129 is going to be confused. This cannot be a reply to my 
65.9.134.4:6969 connection attempt, go away, Castor.

Perhaps you need a SNAT rule in POSTROUTING:
iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
    -d 192.168.0.100 -j SNAT --to 65.9.134.4

A cleaner solution (not sure if applicable to BitTorrent) would be an 
alternate DNS view, so that external clients resolve the name to 
65.9.134.4 whilst internal ones resolve to 192.168.0.100.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Forward internal packets as though they're external

[Jon Heese]

Hmm. Nope.

I added this rule:

iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
      -d 192.168.0.100 -j SNAT --to 65.9.134.4

And I get this error:

SNAT  tcp opt -- in * out *  192.168.0.0/24  -> 192.168.0.100  tcp 
dpt:6969 to:65.9.252.78
iptables: Invalid argument

Seems like it doesn't like the "SNAT" target in the PREROUTING chain (if 
I replace it with "DROP", the rule inserts fine).  Your idea makes 
sense, Rob, but seems like something's still one step away...

Regards,
Jon Heese

/dev/rob0 wrote:
> On Thursday 2005-October-27 08:07, Jon Heese wrote:
> 
>>>Change your DNAT rule to match all the packets you want to match:
>>>
>>>iptables -vt nat -A PREROUTING -d 65.9.134.4 -p tcp --dport 6969 \
>>>    -j DNAT --to 192.168.0.100
>>
>>Except for the --verbose, that's exactly what I'm already doing to
>>DNAT everything from the outside through to castor's 6969.  This rule
>>does not seem to be catching traffic from the inside.  Do I have to
>>do something special to get internal traffic into the PREROUTING
> 
> 
> After I sent this (and went to bed :) ) I realised what must be 
> happening: it's getting the original packet there, but replies are 
> going direct to the IP of the originator.
> 
> Suppose 192.168.0.129 connects to 65.9.134.4:6969 ... the router passes 
> it faithfully on to 192.168.0.100. Now 192.168.0.100 has a packet from 
> 192.168.0.129, and it won't send the reply to 65.9.134.4. The client at 
> 192.168.0.129 is going to be confused. This cannot be a reply to my 
> 65.9.134.4:6969 connection attempt, go away, Castor.
> 
> Perhaps you need a SNAT rule in POSTROUTING:
> iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
>     -d 192.168.0.100 -j SNAT --to 65.9.134.4
> 
> A cleaner solution (not sure if applicable to BitTorrent) would be an 
> alternate DNS view, so that external clients resolve the name to 
> 65.9.134.4 whilst internal ones resolve to 192.168.0.100.

Re: Forward internal packets as though they're external

[/dev/rob0]

On Thursday 2005-October-27 09:38, I wrote:
> Perhaps you need a SNAT rule in POSTROUTING:

That's probably correct.

> iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24
> \ -d 192.168.0.100 -j SNAT --to 65.9.134.4

The example, obviously, is not correct. Copy/paste/PEBKAC error.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Forward internal packets as though they're external

[Jon Heese]

Okay, so I assume you're saying I should try:

iptables -vt nat -A POSTROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
     -d 192.168.0.100 -j SNAT --to 65.9.134.4

Tried that and got no errors running the firewall/nat script, but still 
no go connecting to 65.9.134.4:6969 from 192.168.0.101.

I thought about the scenario, and I think I see why it's not working:

A SYN packet from Webster addressed to 65.9.134.4:6969 goes to the 
router, and the router sends it to Castor because of its DNAT chain. 
Castor gets this packet with a source address of Webster 
(192.168.0.101), and sends back an ACK directly to Webster across the 
local segment, so the packet never has to even cross the router, and 
therefore the SNAT rule I added above is never met.  Webster sees the 
ACK from Castor and throws it away, since it never knowingly tried to 
connect to Castor.

So, it seems there is no simple way to do what I want to do here with 
iptables.  I suppose I'll have to figure out a clever DNS scheme to take 
care of this.

If anyone has any ideas, no matter how complicated, I'd certainly be 
interested in hearing them.

Regards,
Jon Heese

/dev/rob0 wrote:
> On Thursday 2005-October-27 09:38, I wrote:
> 
>>Perhaps you need a SNAT rule in POSTROUTING:
> 
> 
> That's probably correct.
> 
> 
>>iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24
>>\ -d 192.168.0.100 -j SNAT --to 65.9.134.4
> 
> 
> The example, obviously, is not correct. Copy/paste/PEBKAC error.

RE: Forward internal packets as though they're external

[Seferovic Edvin]

Why don't you tell Castor all packages to Webster over the router? Adding an
extra route shouldn't be a problem, and the connection tracking would work
in this way... this way you will need an SNAT over the router to Webster...

Regards,

Edvin

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jon Heese
Sent: Freitag, 28. Oktober 2005 01:32
To: netfilter@lists.netfilter.org
Subject: Re: Forward internal packets as though they're external

Okay, so I assume you're saying I should try:

iptables -vt nat -A POSTROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
     -d 192.168.0.100 -j SNAT --to 65.9.134.4

Tried that and got no errors running the firewall/nat script, but still 
no go connecting to 65.9.134.4:6969 from 192.168.0.101.

I thought about the scenario, and I think I see why it's not working:

A SYN packet from Webster addressed to 65.9.134.4:6969 goes to the 
router, and the router sends it to Castor because of its DNAT chain. 
Castor gets this packet with a source address of Webster 
(192.168.0.101), and sends back an ACK directly to Webster across the 
local segment, so the packet never has to even cross the router, and 
therefore the SNAT rule I added above is never met.  Webster sees the 
ACK from Castor and throws it away, since it never knowingly tried to 
connect to Castor.

So, it seems there is no simple way to do what I want to do here with 
iptables.  I suppose I'll have to figure out a clever DNS scheme to take 
care of this.

If anyone has any ideas, no matter how complicated, I'd certainly be 
interested in hearing them.

Regards,
Jon Heese

/dev/rob0 wrote:
> On Thursday 2005-October-27 09:38, I wrote:
> 
>>Perhaps you need a SNAT rule in POSTROUTING:
> 
> 
> That's probably correct.
> 
> 
>>iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24
>>\ -d 192.168.0.100 -j SNAT --to 65.9.134.4
> 
> 
> The example, obviously, is not correct. Copy/paste/PEBKAC error.

Re: Forward internal packets as though they're external

[Jon Heese]

Ah, I was so caught up in iptables, I wasn't even thinking about 
routing.  Just tried adding a route on Castor to Webster through Router, 
and it works.  Thanks for all the help, Rob and Edvin.

Regards,
Jon Heese

Seferovic Edvin wrote:
> Why don't you tell Castor all packages to Webster over the router? Adding an
> extra route shouldn't be a problem, and the connection tracking would work
> in this way... this way you will need an SNAT over the router to Webster...
> 
> Regards,
> 
> Edvin
> 
> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jon Heese
> Sent: Freitag, 28. Oktober 2005 01:32
> To: netfilter@lists.netfilter.org
> Subject: Re: Forward internal packets as though they're external
> 
> Okay, so I assume you're saying I should try:
> 
> iptables -vt nat -A POSTROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
>      -d 192.168.0.100 -j SNAT --to 65.9.134.4
> 
> Tried that and got no errors running the firewall/nat script, but still 
> no go connecting to 65.9.134.4:6969 from 192.168.0.101.
> 
> I thought about the scenario, and I think I see why it's not working:
> 
> A SYN packet from Webster addressed to 65.9.134.4:6969 goes to the 
> router, and the router sends it to Castor because of its DNAT chain. 
> Castor gets this packet with a source address of Webster 
> (192.168.0.101), and sends back an ACK directly to Webster across the 
> local segment, so the packet never has to even cross the router, and 
> therefore the SNAT rule I added above is never met.  Webster sees the 
> ACK from Castor and throws it away, since it never knowingly tried to 
> connect to Castor.
> 
> So, it seems there is no simple way to do what I want to do here with 
> iptables.  I suppose I'll have to figure out a clever DNS scheme to take 
> care of this.
> 
> If anyone has any ideas, no matter how complicated, I'd certainly be 
> interested in hearing them.
> 
> Regards,
> Jon Heese
> 
> /dev/rob0 wrote:
> 
>>On Thursday 2005-October-27 09:38, I wrote:
>>
>>
>>>Perhaps you need a SNAT rule in POSTROUTING:
>>
>>
>>That's probably correct.
>>
>>
>>
>>>iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24
>>>\ -d 192.168.0.100 -j SNAT --to 65.9.134.4
>>
>>
>>The example, obviously, is not correct. Copy/paste/PEBKAC error.
> 
> 
> 

RE: Forward internal packets as though they're external

[Seferovic Edvin]

You welcome :P 

But please tell us why do you actually want BT in your LAN? Any good
reasons, or just for fun?

Regards,

Edvin

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jon Heese
Sent: Freitag, 28. Oktober 2005 01:50
To: netfilter@lists.netfilter.org
Subject: Re: Forward internal packets as though they're external

Ah, I was so caught up in iptables, I wasn't even thinking about 
routing.  Just tried adding a route on Castor to Webster through Router, 
and it works.  Thanks for all the help, Rob and Edvin.

Regards,
Jon Heese

Seferovic Edvin wrote:
> Why don't you tell Castor all packages to Webster over the router? Adding
an
> extra route shouldn't be a problem, and the connection tracking would work
> in this way... this way you will need an SNAT over the router to
Webster...
> 
> Regards,
> 
> Edvin
> 
> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jon Heese
> Sent: Freitag, 28. Oktober 2005 01:32
> To: netfilter@lists.netfilter.org
> Subject: Re: Forward internal packets as though they're external
> 
> Okay, so I assume you're saying I should try:
> 
> iptables -vt nat -A POSTROUTING -p tcp --dport 6969 -s 192.168.0.0/24 \
>      -d 192.168.0.100 -j SNAT --to 65.9.134.4
> 
> Tried that and got no errors running the firewall/nat script, but still 
> no go connecting to 65.9.134.4:6969 from 192.168.0.101.
> 
> I thought about the scenario, and I think I see why it's not working:
> 
> A SYN packet from Webster addressed to 65.9.134.4:6969 goes to the 
> router, and the router sends it to Castor because of its DNAT chain. 
> Castor gets this packet with a source address of Webster 
> (192.168.0.101), and sends back an ACK directly to Webster across the 
> local segment, so the packet never has to even cross the router, and 
> therefore the SNAT rule I added above is never met.  Webster sees the 
> ACK from Castor and throws it away, since it never knowingly tried to 
> connect to Castor.
> 
> So, it seems there is no simple way to do what I want to do here with 
> iptables.  I suppose I'll have to figure out a clever DNS scheme to take 
> care of this.
> 
> If anyone has any ideas, no matter how complicated, I'd certainly be 
> interested in hearing them.
> 
> Regards,
> Jon Heese
> 
> /dev/rob0 wrote:
> 
>>On Thursday 2005-October-27 09:38, I wrote:
>>
>>
>>>Perhaps you need a SNAT rule in POSTROUTING:
>>
>>
>>That's probably correct.
>>
>>
>>
>>>iptables -vt nat -A PREROUTING -p tcp --dport 6969 -s 192.168.0.0/24
>>>\ -d 192.168.0.100 -j SNAT --to 65.9.134.4
>>
>>
>>The example, obviously, is not correct. Copy/paste/PEBKAC error.
> 
> 
> 

Re: Forward internal packets as though they're external

[Jon Heese]

I'm running the BitTorrent *tracker* here on my local network.  I have a 
dedicated high-bandwidth server offsite that is seeding the torrents. 
The torrent has hardcoded into it the location of the tracker 
(http://dns.name.of.my.router:6969/announce), so if I want to download 
torrents to a machine on the LAN here, I have to be able to connect to 
that machine on that port.

Does that make sense?

Regards,
Jon Heese

Seferovic Edvin wrote:
> You welcome :P 
> 
> But please tell us why do you actually want BT in your LAN? Any good
> reasons, or just for fun?
> 
> Regards,
> 
> Edvin
> 
> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Jon Heese
> Sent: Freitag, 28. Oktober 2005 01:50
> To: netfilter@lists.netfilter.org
> Subject: Re: Forward internal packets as though they're external
> 
> Ah, I was so caught up in iptables, I wasn't even thinking about 
> routing.  Just tried adding a route on Castor to Webster through Router, 
> and it works.  Thanks for all the help, Rob and Edvin.
> 
> Regards,
> Jon Heese
> 
> Seferovic Edvin wrote:
> 
>>Why don't you tell Castor all packages to Webster over the router? Adding
> 
> an
> 
>>extra route shouldn't be a problem, and the connection tracking would work
>>in this way... this way you will need an SNAT over the router to
> 
> Webster...
> 
>>Regards,
>>
>>Edvin