nat problem

nat problem

[Frans Luteijn]

Dear Sirs,

I have a little problem, which might be a bug. I have an 3COM
ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
internal net. Now I want to forward those broadcasts to another network.
This is the situation:


+------+    +--------+    +--------+
|ISDN- |    |        |    |Internal|
|router|----|firewall|----|network |
+------+    |        |    +--------+
            +--------+
                |
                |
                |
            +------+
            |ADSL- |
            |router|
            +------+


The ISDN-router has 192.168.1.1/24, the ADSL-router has 172.19.3.1/16,
the firewall has at eth0 192.168.1.4, at eth1 172.19.3.2 and at eth2
192.168.2.1. The internal network is 192.168.2.0/24.

The firewall is a Debian-Linux with a 2.4.26 kernel with Nat enabled.

After reading of all the nesesary HOWTO's, I decided that that
forwarding should be done with prerouting. To know what I have to
forward, I have to know what the packets are. I turned logging on for
that interface, and if I can log the packets, I can also manipulate
them.
So I typed:

iptables -t nat -A PREROUTING -i eth0 -j LOG

and waited for the packets to come by. But nothing happened. Althought I
could see some other packets coming in. From my log:

Jul  2 16:38:16 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19499 PROTO=UDP
SPT=138 DPT=138 LEN=220
Jul  2 16:43:40 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19755 PROTO=UDP
SPT=138 DPT=138 LEN=220

Those are from a machine that will be moved to my internal network

Then I typed:

iptables -A INPUT -i eth0 -j LOG

and there were the packets:

Jul  2 16:47:43 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48404 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:47:53 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48405 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:48:03 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48406 PROTO=UDP
SPT=1025 DPT=2071 LEN=96

In /proc/net/ip_conntrack I can see:

udp      17 27 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
[UNREPLIED] src=192.168.1.255 dst=192.168.1.3 sport=138 dport=138 use=1
udp      17 20 src=192.168.1.1 dst=192.168.1.255 sport=1025 dport=2071
[UNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=2071 dport=1025
use=1
.......


Now are my questions:
am I doing something wrong, e.g. shouldn't it be prerouting;
can't it be done, because of the sourceport and the destport are
different;
is it a bug in the nat-software or is it intended to work that way?

If you need some extra information, I am happily to provide it.

Yours Sincerely,
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Monday 05 July 2004 5:33 pm, Frans Luteijn wrote:

> Dear Sirs,
>
> I have a little problem, which might be a bug. I have an 3COM
> ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> internal net.

What do yuo mean by "broadcasts"?   What protocol is being used?   What 
address are the packets sent to?

> Now I want to forward those broadcasts to another network.

If, by broadcasts, you mean packets addressed to the "broadcast address" of 
your subnet, it can't be done - you cannot route broadcast packets across a 
router (that's why people use bridges).   The only way it could be done is to 
have a machine which understands the protocol, and is connected to both 
networks, picking up the broadcast packets on one subnet, and then creating 
new broadcast packets to send to the other network (and, of course, dealign 
sensibly with the replies).

This, for example, is how you get Windows NetBios share browsing to work 
across network boundaries - it's not pretty, but if broadcast packets are 
what you're starting from then it's the only way.

Regards,

Antony.

-- 
I love deadlines.   I love the whooshing noise they make as they go by.

 - Douglas Noel Adams

                                                     Please reply to the list;
                                                           please don't CC me.

nat problem

[Frans Luteijn]

Dear sirs, madams,

I have a little problem, which might be a bug. I have an 3COM
ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
internal net. Now I want to forward those broadcasts to another network.

This is the situation:


+------+    +--------+    +--------+
|ISDN- |    |        |    |Internal|
|router|----|firewall|----|network |
+------+    |        |    +--------+
            +--------+
                |
                |
                |
            +------+
            |ADSL- |
            |router|
            +------+


The ISDN-router has 192.168.1.1/24, the ADSL-router has 172.19.3.1/16,
the firewall has at eth0 192.168.1.4, at eth1 172.19.3.2 and at eth2
192.168.2.1. The internal network is 192.168.2.0/24.

The firewall is a Debian-Linux with a 2.4.26 kernel with Nat enabled.

After reading of all the nesesary HOWTO's, I decided that that
forwarding should be done with prerouting. To know what I have to
forward, I have to know what the packets are. I turned logging on for
that interface, and if I can log the packets, I can also manipulate
them.
So I typed:

iptables -t nat -A PREROUTING -i eth0 -j LOG

and waited for the packets to come by. But nothing happened. Althought I

could see some other packets coming in. From my log:

Jul  2 16:38:16 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19499 PROTO=UDP
SPT=138 DPT=138 LEN=220
Jul  2 16:43:40 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=19755 PROTO=UDP
SPT=138 DPT=138 LEN=220

Those are from a machine that will be moved to my internal network

Then I typed:

iptables -A INPUT -i eth0 -j LOG

and there were the packets:

Jul  2 16:47:43 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48404 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:47:53 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48405 PROTO=UDP
SPT=1025 DPT=2071 LEN=96
Jul  2 16:48:03 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1
DST=192.168.1.255 LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=48406 PROTO=UDP
SPT=1025 DPT=2071 LEN=96

In /proc/net/ip_conntrack I can see:

udp      17 27 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
[UNREPLIED] src=192.168.1.255 dst=192.168.1.3 sport=138 dport=138 use=1
udp      17 20 src=192.168.1.1 dst=192.168.1.255 sport=1025 dport=2071
[UNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=2071 dport=1025
use=1
.......


Now are my questions:
am I doing something wrong, e.g. shouldn't it be prerouting;
can't it be done, because of the sourceport and the destport are
different;
is it a bug in the nat-software or is it intended to work that way?

If you need some extra information, I am happily to provide it.

Yours Sincerely,
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:

> I have a little problem, which might be a bug. I have an 3COM
> ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> internal net. Now I want to forward those broadcasts to another network.

On Wednesday 07 July 2004 2:07 pm, Antony Stone wrote:

> On Monday 05 July 2004 5:33 pm, Frans Luteijn wrote:
> >
> > I have a little problem, which might be a bug. I have an 3COM
> > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > internal net.
>
> What do yuo mean by "broadcasts"?   What protocol is being used?   What
> address are the packets sent to?
>
> > Now I want to forward those broadcasts to another network.
>
> If, by broadcasts, you mean packets addressed to the "broadcast address" of
> your subnet, it can't be done - you cannot route broadcast packets across a
> router (that's why people use bridges).   The only way it could be done is
> to have a machine which understands the protocol, and is connected to both
> networks, picking up the broadcast packets on one subnet, and then creating
> new broadcast packets to send to the other network (and, of course, dealign
> sensibly with the replies).
>
> This, for example, is how you get Windows NetBios share browsing to work
> across network boundaries - it's not pretty, but if broadcast packets are
> what you're starting from then it's the only way.
>
> Regards,
>
> Antony.

-- 
"Linux is going to be part of the future. It's going to be like Unix was."

 - Peter Moore, Asia-Pacific general manager, Microsoft

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:
>
> > I have a little problem, which might be a bug. I have an 3COM
> > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > internal net. Now I want to forward those broadcasts to another network.
>
> On Wednesday 07 July 2004 2:07 pm, Antony Stone wrote:
>
> > On Monday 05 July 2004 5:33 pm, Frans Luteijn wrote:
> > >
> > > I have a little problem, which might be a bug. I have an 3COM
> > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > internal net.
> >
> > What do yuo mean by "broadcasts"?   What protocol is being used?   What
> > address are the packets sent to?

These are real broadcasts to 192.168.1.255. The protocol is UDP, the source port
is 1025 and the destination port is 2071.Isn't it weird, that at the nat-table,
when I add a rule for logging, I can't see the above meant packets, but at the
filter- and the mangle-table those packets are logged?

At a company I worked for, DHCP broadcasts were sent from one network to another,
so it should be possible.

> >
> > > Now I want to forward those broadcasts to another network.
> >
> > If, by broadcasts, you mean packets addressed to the "broadcast address" of
> > your subnet, it can't be done - you cannot route broadcast packets across a
> > router (that's why people use bridges).   The only way it could be done is
> > to have a machine which understands the protocol, and is connected to both
> > networks, picking up the broadcast packets on one subnet, and then creating
> > new broadcast packets to send to the other network (and, of course, dealign
> > sensibly with the replies).

This is exactly what I mean. I want to forward the broadcastpackets from
192.168.1.255 to 192.168.2.255. I don't want to use a bridge here. I want those
networks separated, so I can share the connection to others without concerning
they can see my private network.

> >
> > This, for example, is how you get Windows NetBios share browsing to work
> > across network boundaries - it's not pretty, but if broadcast packets are
> > what you're starting from then it's the only way.
> >
> > Regards,
> >
> > Antony.
>
> --
> "Linux is going to be part of the future. It's going to be like Unix was."
>
>  - Peter Moore, Asia-Pacific general manager, Microsoft
>
>                                                      Please reply to the list;
>                                                            please don't CC me.



--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Tuesday 13 July 2004 11:21 pm, Frans Luteijn wrote:

> Antony Stone schreef:
> > On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:
> > > I have a little problem, which might be a bug. I have an 3COM
> > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > internal net. Now I want to forward those broadcasts to another
> > > network.
> >
> > > What do you mean by "broadcasts"?   What protocol is being used?   What
> > > address are the packets sent to?
>
> These are real broadcasts to 192.168.1.255. The protocol is UDP, the source
> port is 1025 and the destination port is 2071.Isn't it weird, that at the
> nat-table, when I add a rule for logging, I can't see the above meant
> packets, but at the filter- and the mangle-table those packets are logged?

No, I don't think so.   Broadcast packets are not supposed to cross routers 
(they will enter the router as a machine on the local subnet, but they will 
not be routed anywhere else, because they already come from the subnet they 
are addressed to)

> At a company I worked for, DHCP broadcasts were sent from one network to
> another, so it should be possible.

I would suggest that the network you refer to had a DHCP relay server on it.

> > > > Now I want to forward those broadcasts to another network.
> > >
> > > If, by broadcasts, you mean packets addressed to the "broadcast
> > > address" of your subnet, it can't be done - you cannot route broadcast
> > > packets across a router (that's why people use bridges).   The only way
> > > it could be done is to have a machine which understands the protocol,
> > > and is connected to both networks, picking up the broadcast packets on
> > > one subnet, and then creating new broadcast packets to send to the
> > > other network (and, of course, dealign sensibly with the replies).
>
> This is exactly what I mean. I want to forward the broadcastpackets from
> 192.168.1.255 to 192.168.2.255. I don't want to use a bridge here. I want
> those networks separated, so I can share the connection to others without
> concerning they can see my private network.

In that case put a DHCP relay server on the subnet on which the broadcasts are 
being generated, and configure it to forward the packets to the DHCP server 
on the other subnet.

You cannot use netfilter to do this, simply because broadcast packets don't 
cross routers.   That is why DHCP relays exist.


Regards,

Antony.

-- 
How I want a drink, alcoholic of course, after the heavy chapters involving 
quantum mechanics.

 - 3.14159265358979

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Nick Taylor]

> > > > I have a little problem, which might be a bug. I have an 3COM
> > > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > > internal net. Now I want to forward those broadcasts to another
> > > > network.
> > >
> > > > What do you mean by "broadcasts"?   What protocol is being used?   What
> > > > address are the packets sent to?
> >
> > These are real broadcasts to 192.168.1.255. The protocol is UDP, the source
> > port is 1025 and the destination port is 2071.Isn't it weird, that at the
> > nat-table, when I add a rule for logging, I can't see the above meant
> > packets, but at the filter- and the mangle-table those packets are logged?
>
> No, I don't think so.   Broadcast packets are not supposed to cross routers
> (they will enter the router as a machine on the local subnet, but they will
> not be routed anywhere else, because they already come from the subnet they
> are addressed to)
>
Not to be contrary, and *NOT* to suggest that this is correct behaviour,
but...  The company I used to work for uses a lot of LinkSys gear for CPE,
including their NAT routers and their VPN routers, and we've had bizarre
problems with these products.  The VPN router, in particular *will*
forward a packet with the destination address set to the IP broadcast
address!  Then, they run NAT rules beyond the VPN server at the other
side, so you get:
192.168.1.43 -> 192.168.1.255, which getts natted to:
real_ip -> 192.168.1.255, but of course, that's behind the VPN tunnel, so,
the box routes it back through the VPN, where it gets spit out on the
customer's lan, (thankfully NOT forwarded back again) but this confuses
Windoze something aweful, and causes it to refuse to use windows
networking, because it thinks there's another machine on the network with
it's name registered. DOH!  Anyway, the point is that while it may or may
not be correct, many products do it, and there must be some (twisted)
reason that the hardware vendors chose to enhance (read break) their
products in this way, ie, some application may depend on this (braindead)
behaviour.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Tuesday 13 July 2004 11:21 pm, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > > On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:
> > > > I have a little problem, which might be a bug. I have an 3COM
> > > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > > internal net. Now I want to forward those broadcasts to another
> > > > network.
> > >
> > > > What do you mean by "broadcasts"?   What protocol is being used?   What
> > > > address are the packets sent to?
> >
> > These are real broadcasts to 192.168.1.255. The protocol is UDP, the source
> > port is 1025 and the destination port is 2071.Isn't it weird, that at the
> > nat-table, when I add a rule for logging, I can't see the above meant
> > packets, but at the filter- and the mangle-table those packets are logged?
>
> No, I don't think so.   Broadcast packets are not supposed to cross routers
> (they will enter the router as a machine on the local subnet, but they will
> not be routed anywhere else, because they already come from the subnet they
> are addressed to)
>

I have been doing some testing:I have a machine, which broadcasts to 192.168.1.255
prot.: udp sport/dport: 138/138
I typed in:

iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138 -j LOG
iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138 -j DNAT
192.168.2.255

Then I saw in my log:
Jul 14 02:34:16 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3 DST=192.168.1.255
LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=60162 PROTO=UDP SPT=138 DPT=138 LEN=220

and I saw trafic on my other network.
When I type:

cat /proc/net/ip_conntrack

I see:
udp      17 17 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138 [UNREPLIED]
src=192.168.2.255 dst=192.168.1.3 sport=138 dport=138 use=1

This means to me, that those packets are forwarded. So why can't I forward the
other packets (192.168.1.255, prot.: udp, sport/dport: 1025/2071)?

> > At a company I worked for, DHCP broadcasts were sent from one network to
> > another, so it should be possible.
>
> I would suggest that the network you refer to had a DHCP relay server on it.
>
> > > > > Now I want to forward those broadcasts to another network.
> > > >
> > > > If, by broadcasts, you mean packets addressed to the "broadcast
> > > > address" of your subnet, it can't be done - you cannot route broadcast
> > > > packets across a router (that's why people use bridges).   The only way
> > > > it could be done is to have a machine which understands the protocol,
> > > > and is connected to both networks, picking up the broadcast packets on
> > > > one subnet, and then creating new broadcast packets to send to the
> > > > other network (and, of course, dealign sensibly with the replies).
> >
> > This is exactly what I mean. I want to forward the broadcastpackets from
> > 192.168.1.255 to 192.168.2.255. I don't want to use a bridge here. I want
> > those networks separated, so I can share the connection to others without
> > concerning they can see my private network.
>
> In that case put a DHCP relay server on the subnet on which the broadcasts are
> being generated, and configure it to forward the packets to the DHCP server
> on the other subnet.
>
> You cannot use netfilter to do this, simply because broadcast packets don't
> cross routers.   That is why DHCP relays exist.
>
> Regards,
>
> Antony.
>
> --
> How I want a drink, alcoholic of course, after the heavy chapters involving
> quantum mechanics.
>
>  - 3.14159265358979
>
>                                                      Please reply to the list;
>                                                            please don't CC me.



--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B

Re: nat problem

[Antony Stone]

On Wednesday 14 July 2004 2:02 am, Frans Luteijn wrote:

> Antony Stone schreef:
> >
> > No, I don't think so.   Broadcast packets are not supposed to cross
> > routers (they will enter the router as a machine on the local subnet, but
> > they will not be routed anywhere else, because they already come from the
> > subnet they are addressed to)
>
> I have been doing some testing:I have a machine, which broadcasts to
> 192.168.1.255 prot.: udp sport/dport: 138/138
> I typed in:
>
> iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138
> -j LOG iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp
> --sport 138 -j DNAT 192.168.2.255
>
> Then I saw in my log:
> Jul 14 02:34:16 firewall kernel: IN=eth0 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
> DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=60162 PROTO=UDP
> SPT=138 DPT=138 LEN=220
>
> and I saw trafic on my other network.
> When I type:
>
> cat /proc/net/ip_conntrack
>
> I see:
> udp      17 17 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
> [UNREPLIED] src=192.168.2.255 dst=192.168.1.3 sport=138 dport=138 use=1
>
> This means to me, that those packets are forwarded. So why can't I forward
> the other packets (192.168.1.255, prot.: udp, sport/dport: 1025/2071)?

What happens if you try the same test as above, but with the port numbers you 
are interested in?   Do the connection tracking table and the log file 
suggest that packets are being forwarded?   If you can get it to "work" on 
port 138, I don't see why it shouldn't "work" on port 2071.

BTW: I put "work" in quotes there because although you see the packets going 
through the firewall, does the actual NetBios service allow you to browse 
Windows shares on machines on the other subnet?   My expectation is not, 
because there have been many questions on this list previously about share 
browsing across routers (Windows does network browsing using broadcast 
packets), the solution to which has always been a PDC on the source network, 
with knowledge of the second subnet.

Regards,

Antony.

-- 
I think, therefore I am.
I'm pink, therefore I'm Spam.
I drink, therefore I think I am.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Wednesday 14 July 2004 2:02 am, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > >
> > > No, I don't think so.   Broadcast packets are not supposed to cross
> > > routers (they will enter the router as a machine on the local subnet, but
> > > they will not be routed anywhere else, because they already come from the
> > > subnet they are addressed to)
> >
> > I have been doing some testing:I have a machine, which broadcasts to
> > 192.168.1.255 prot.: udp sport/dport: 138/138
> > I typed in:
> >
> > iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138
> > -j LOG iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp
> > --sport 138 -j DNAT 192.168.2.255
> >
> > Then I saw in my log:
> > Jul 14 02:34:16 firewall kernel: IN=eth0 OUT=
> > MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
> > DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=60162 PROTO=UDP
> > SPT=138 DPT=138 LEN=220
> >
> > and I saw trafic on my other network.
> > When I type:
> >
> > cat /proc/net/ip_conntrack
> >
> > I see:
> > udp      17 17 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
> > [UNREPLIED] src=192.168.2.255 dst=192.168.1.3 sport=138 dport=138 use=1
> >
> > This means to me, that those packets are forwarded. So why can't I forward
> > the other packets (192.168.1.255, prot.: udp, sport/dport: 1025/2071)?
>
> What happens if you try the same test as above, but with the port numbers you
> are interested in?   Do the connection tracking table and the log file
> suggest that packets are being forwarded?   If you can get it to "work" on
> port 138, I don't see why it shouldn't "work" on port 2071.
>

Nothing happens, no logging or anything else:iptables -t nat -A PREROUTING -i eth0
-d 192.168.1.255 -p udp --sport 1025 -j LOG
iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 1025 -j DNAT
--to 192.168.2.255

When I type:
cat /proc/net/ip_conntrack
I see:
udp      17 25 src=192.168.1.1 dst=192.168.1.255 sport=1025 dport=2071 [UNREPLIED]
src=192.168.1.255 dst=192.168.1.1 sport=2071 dport=1025 use=1

After typing:
iptables -t nat -I PREROUTING 2 -i eth0 -d 192.168.1.255 -p udp --sport 2071 -j
LOG
iptables -t nat -I PREROUTING 3 -i eth0 -d 192.168.1.255 -p udp --dport 1025 -j
LOG
iptables -t nat -I PREROUTING 4 -i eth0 -d 192.168.1.255 -p udp --dport 2071 -j
LOG
nothing happens either.

But after typing:
iptables -t filter -A INPUT -i eth0 -d 192.168.1.255 -p udp --sport 1025 -j LOG
I see the packets coming in:
Jul 15 00:59:11 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31435 PROTO=UDP SPT=1025 DPT=2071 LEN=96
Jul 15 00:59:21 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31436 PROTO=UDP SPT=1025 DPT=2071 LEN=96
Jul 15 00:59:31 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31437 PROTO=UDP SPT=1025 DPT=2071 LEN=96

So what is wrong here? I think, it is a bug, because it doesn't work as expected.

> BTW: I put "work" in quotes there because although you see the packets going
> through the firewall, does the actual NetBios service allow you to browse
> Windows shares on machines on the other subnet?   My expectation is not,
> because there have been many questions on this list previously about share
> browsing across routers (Windows does network browsing using broadcast
> packets), the solution to which has always been a PDC on the source network,
> with knowledge of the second subnet.
>

That was not my intention. This was only an example to show you, it is possible to
forward broadcastpackets to another network.

> Regards,
>
> Antony.
>
> --
> I think, therefore I am.
> I'm pink, therefore I'm Spam.
> I drink, therefore I think I am.
>
>                                                      Please reply to the list;
>                                                            please don't CC me.

--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B
GPG PblKey fprnt=ED20 0F25 C233 DC59 3FFA  170E D0BF 15F5 0BA6 1355

Re: nat problem

[Antony Stone]

On Thursday 15 July 2004 12:30 am, Frans Luteijn wrote:

> Antony Stone schreef:
> >
> > What happens if you try the same test as above, but with the port numbers
> > you are interested in?   Do the connection tracking table and the log
> > file suggest that packets are being forwarded?   If you can get it to
> > "work" on port 138, I don't see why it shouldn't "work" on port 2071.
>
> Nothing happens, no logging or anything else
>
> So what is wrong here? I think, it is a bug, because it doesn't work as
> expected.

Well, I don't think it can be called a bug in netfilter (I may be wrong), 
because there's nothing about netfilter which should make NAT for one port 
any different from NAT for another port.

I'm surprised you got the port 138 packets to be forwarded; I don't know why 
the two are behaving differently.

> > BTW: I put "work" in quotes there because although you see the packets
> > going through the firewall, does the actual NetBios service allow you to
> > browse Windows shares on machines on the other subnet?   My expectation
> > is not, because there have been many questions on this list previously
> > about share browsing across routers (Windows does network browsing using
> > broadcast packets), the solution to which has always been a PDC on the
> > source network, with knowledge of the second subnet.
>
> That was not my intention. This was only an example to show you, it is
> possible to forward broadcast packets to another network.

Oh, sure - I knew you didn't actually *want* to use port 138, but I was still 
interested to know whether, having got the packets to cross the router, they 
would work and provide your witha  working service.   If not, then it's a bit 
moot as to whether you can forward the broadcasts or not.

I hope someone else here can suggest whether (and if so, how) it's possible to 
do what you want - I didn't think it was, but you've obviously got more to 
work than I had expected possible.

Regards,

Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the sense of 
achievement you get from getting them to work at all. In other words - and 
this is the rock solid principle on which the whole of the Corporation's 
Galaxy-wide success is founded - their fundamental design flaws are 
completely hidden by their superficial design flaws."

 - Douglas Noel Adams

                                                     Please reply to the list;
                                                           please don't CC me.

Re: nat problem

[Frans Luteijn]

Antony Stone schreef:

> On Thursday 15 July 2004 12:30 am, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > >
> > > What happens if you try the same test as above, but with the port numbers
> > > you are interested in?   Do the connection tracking table and the log
> > > file suggest that packets are being forwarded?   If you can get it to
> > > "work" on port 138, I don't see why it shouldn't "work" on port 2071.
> >
> > Nothing happens, no logging or anything else
> >
> > So what is wrong here? I think, it is a bug, because it doesn't work as
> > expected.
>
> Well, I don't think it can be called a bug in netfilter (I may be wrong),
> because there's nothing about netfilter which should make NAT for one port
> any different from NAT for another port.
>
> I'm surprised you got the port 138 packets to be forwarded; I don't know why
> the two are behaving differently.

Maybe because in the 138-case the sport and the dport are the same and
in the
other case they are different? Or the sport and dport are above 1024? I
don't know
either. Who should I ask, any suggestion?

>

(snip)

>
>
>
> I hope someone else here can suggest whether (and if so, how) it's possible to
> do what you want - I didn't think it was, but you've obviously got more to
> work than I had expected possible.

What is a broadcastpacket different from any other packet, except that
every
computer on the network can respond to it? So it can be treated as any
other
packet.

>
>
> Regards,
>
> Antony.
>

P.S.
Sorry for the late response, for some strange reason I didn't receive
any mail from this list any more for two days. I had to look up the
answer in the archieves.

Regards,
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1  EF 42 A1 9A E2 C0 42 5B
GPG PblKey fprnt=ED20 0F25 C233 DC59 3FFA  170E D0BF 15F5 0BA6 1355

NAT problem

[Jose Pascual]

Hi all,
I am new using iptables and surelly  this wil be an easy and stupid question
but perhaps you can help me. I want to understand NAT so I am trying to do
the following:

I have three computers in my LAN (192.168.1.1; 192.168.1.2 and 192.168.1.3).
192.168.1.1 has a web server and I would like to access it through
192.168.1.2 with NAT. For example openning my browser in 192.168.1.3 and
connecting to 192.168.1.2   I  should see the same as if I connected to
192.168.1.1 web server directly, so I have done the following in
192.168.1.2:

 iptables -t nat -A PREROUTING -p tcp --dport 80 -j
DNAT --to-destination 192.168.1.1


 iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
--to-source 192.168.1.2

However it doesn't work. Anyone can help me?

Thanks

Regards
Jose Pascual

Re: NAT problem

[Venkatesh. K]

What you are trying to do is not possible with a straight forward
configuration.

You have to get the concept of DNAT right. DNAT only works when the DNAT ip
address is on seperate subnet.

For example,

192.168.0.1 <-> 192.168.0.254 <-> 192.168.1.1

you can DNAT requests coming from 192.168.0.1 to 192.168.0.254 to
192.168.1.1 by doing

/sbin/iptables -t nat -I PREROUTING -s 192.168.0.1 -p tcp --dport www -j
DNAT --to-destination 192.168.1.1

Venkatesh K

----- Original Message ----- 
From: "Jose Pascual" <jose.pascual@optivamedia.com>
To: <netfilter@lists.netfilter.org>
Sent: Monday, October 06, 2003 6:00 PM
Subject: NAT problem


> Hi all,
> I am new using iptables and surelly  this wil be an easy and stupid
question
> but perhaps you can help me. I want to understand NAT so I am trying to do
> the following:
>
> I have three computers in my LAN (192.168.1.1; 192.168.1.2 and
192.168.1.3).
> 192.168.1.1 has a web server and I would like to access it through
> 192.168.1.2 with NAT. For example openning my browser in 192.168.1.3 and
> connecting to 192.168.1.2   I  should see the same as if I connected to
> 192.168.1.1 web server directly, so I have done the following in
> 192.168.1.2:
>
>  iptables -t nat -A PREROUTING -p tcp --dport 80 -j
> DNAT --to-destination 192.168.1.1
>
>
>  iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
> --to-source 192.168.1.2
>
> However it doesn't work. Anyone can help me?
>
> Thanks
>
> Regards
> Jose Pascual
>
>
>
>
>

Re: NAT problem

[Cedric Blancher]

Le lun 06/10/2003 à 15:19, Venkatesh. K a écrit :
> You have to get the concept of DNAT right. DNAT only works when the DNAT ip
> address is on seperate subnet.

You can DNAT to the same subnet providing you SNAT the forwarded flow
with redirector IP.

192.168.1.3 ----> 192.168.1.2 ----> 192.168.1.1

On 192.168.1.2 :

	iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT \
		--to 192.168.1.1
	iptables -t nat -A POSTROUTING -p tcp -d 182.168.1.1 \
		--dport 80 -j SNAT --to 192.168.1.2

This prevent 192.168.1.3 to reply 192.168.1.2 directly, ans thus
confusing 192.168.1.1. It's a common issue for people thrying to reach
an inside host belonging to the same subnet via its public DNAT IP.

From OP :
>> iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
>> --to-source 192.168.1.2

This is not needed as returning packets for natted connections are
automaticly handled through conntrack engine.

By the way, I would have set this up using a simple TCP port redirector
like redir.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: NAT problem

[Joel Newkirk]

Your SNAT rule should be matching dport, not sport.

Do you have a rule in FORWARD table on 192.168.1.2 that ACCEPTs this
traffic?  And is 192.168.1.2 configured to even allow forwarding?

j

On Mon, 2003-10-06 at 08:30, Jose Pascual wrote:
> Hi all,
> I am new using iptables and surelly  this wil be an easy and stupid question
> but perhaps you can help me. I want to understand NAT so I am trying to do
> the following:
> 
> I have three computers in my LAN (192.168.1.1; 192.168.1.2 and 192.168.1.3).
> 192.168.1.1 has a web server and I would like to access it through
> 192.168.1.2 with NAT. For example openning my browser in 192.168.1.3 and
> connecting to 192.168.1.2   I  should see the same as if I connected to
> 192.168.1.1 web server directly, so I have done the following in
> 192.168.1.2:
> 
>  iptables -t nat -A PREROUTING -p tcp --dport 80 -j
> DNAT --to-destination 192.168.1.1
> 
> 
>  iptables -t nat -A POSTROUTING -p tcp --sport 80 -j SNAT
> --to-source 192.168.1.2
> 
> However it doesn't work. Anyone can help me?
> 
> Thanks
> 
> Regards
> Jose Pascual
> 

RE: nat problem...

[Yogini Parkhi]

Hi Rahul,
Couple of tips that might help you...
1: 
Use "iptables -L -v -n"
Look at the packet and byte counters in there and see which ones of your accept rules actually are accepting packets.

2:
Also a log rule at the end of your FORWARD chain might help identify what kinds of packets are getting dropped.  The log rule will look something like
$iptables -A FORWARD -m limit -j LOG -log-prefix "RAHULS_LOG"
This will log packets to your syslog "/var/log/messages" usually. You can observ those and debug further.

I suspect your syn packets are getting dropped. 
Add the following rule right before: "$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 80 -j ACCEPT" This rule you have.

$iptables -A FORWARD -p tcp -i $extra_dev --syn --dport 80 -j ACCEPT

Hopefully this rule will solve your immediate issue. Then the packet and byte counters will point out the unnecessary rules to you and you can remove those.

Hope this helps,
-Yogini




-----Original Message-----
From: Rahul Jadhav [mailto:rahul@iatp.org]
Sent: Friday, November 15, 2002 12:45 PM
To: netfilter@lists.netfilter.org
Subject: nat problem...

I have a setup without a dmz, ie, the servers (http, mail, ssh) share the same subnet as my intranet clients (dhcp). The iptables script I am struggling with allows clients to browse the net but refuses them connections to the servers. Somehow the firewall refuses tcp/udp connections meant for the servers. The firewall machine runs no public services (forwards traffic only).
the forward and nat rules that i use are

public_ip=external web ip
intra_dev=internal iface
extra_dev=external iface
intra_ip=internal ip
extra_ip=external ip
http=http server ip
mail=mail server ip

# forward
$iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# do I need these 2 lines
$iptables -A FORWARD -p tcp -i $intra_dev -o $extra_dev -j ACCEPT
$iptables -A FORWARD -p udp -i $intra_dev -o $extra_dev -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 80 -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 81 -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 80 -d $http -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 81 -d $mail -j ACCEPT

# prerouting
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 80 -j DNAT --to $http
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 81 -j DNAT --to $mail

# postrouting
# either these 2 rules or the masquerade rule works

$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip
$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip

$iptables -A POSTROUTING -t nat -o $extra_dev -j MASQUERADE

does someone see a problem that I can't. Also, could someone enlighten me about the output chain and whether or not I need it here.
Thanks

Rahul

nat problem...

[Rahul Jadhav]

I have a setup without a dmz, ie, the servers (http, mail, ssh) share the same subnet as my intranet clients (dhcp). The iptables script I am struggling with allows clients to browse the net but refuses them connections to the servers. Somehow the firewall refuses tcp/udp connections meant for the servers. The firewall machine runs no public services (forwards traffic only).
the forward and nat rules that i use are 

public_ip=external web ip
intra_dev=internal iface
extra_dev=external iface
intra_ip=internal ip
extra_ip=external ip
http=http server ip
mail=mail server ip

# forward
$iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# do I need these 2 lines
$iptables -A FORWARD -p tcp -i $intra_dev -o $extra_dev -j ACCEPT
$iptables -A FORWARD -p udp -i $intra_dev -o $extra_dev -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 80 -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -m state --state NEW,ESTABLISHED,RELATED --dport 81 -j ACCEPT

$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 80 -d $http -j ACCEPT
$iptables -A FORWARD -p tcp -i $extra_dev -o $intra_dev --dport 81 -d $mail -j ACCEPT

# prerouting
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 80 -j DNAT --to $http
$iptables -A PREROUTING -t nat -p tcp -i $extra_dev -d $public_ip --dport 81 -j DNAT --to $mail

# postrouting
# either these 2 rules or the masquerade rule works

$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip
$iptables -A POSTROUTING -t nat -p tcp -o $extra_dev -s $intra_lan -d $universe -j SNAT --to $extra_ip

$iptables -A POSTROUTING -t nat -o $extra_dev -j MASQUERADE

does someone see a problem that I can't. Also, could someone enlighten me about the output chain and whether or not I need it here.
Thanks

Rahul

NAT problem

[saravanan sakthi]

  Here is my sinario...
        |             
     ___v__________________
    | eth0: 192.168.1.3/24 |
    |                      |
    |     Linux Box        |
    |                      |
    | eth1: 10.1.1.1/16    |
    `---|------------------'
        |
    ____v________________________________________
   /                                             \
  |   10.1.0.0 network                            \
  |                                                \
  |       ____________         __________           |
  |      /            \       /           \         |
  |     | 10.1.11.0/16 |     | 10.1.9.0/16 |        |
  |     |   network    |     |   network   |        |
  |      \____________/       \___________/         |
  |                                                 |
  |       _____________________________             |
  |      /                             \            |
  |     | 10.1.12.0 (My Network)        \           |
  |     |         |                      \          |
  |     |         |                       \         |
  |     |      ___v________________        |        |
  |     |     | eth0: 10.1.12.1/16 |       |       /
  |     |     |                    |       |      /
  |     |     |    Linux Box       |       |     /
  |     |     |                    |      /     /
  |     |     | eth1: 10.0.0.1/8   |     /     /
  |     |     `---|----------------'    /     /
  |     |         |                    /     /
  |     |        _v________           /     /
  |     |       /          \         /     /
  |     |      | 10.0.0.0/8 |       /     /
  |     |      | network    |      /     /
  |      \      \__________/      /     /
   \      \                      /     /
    \      \____________________/     /
     \                               /
      \_____________________________/

Here

  * The Linux box at the beginning acts as a gateway
and DNS forwarder
    for the entire network (installed with
rc.firewall-2.4).

  * My network is 10.1.12.0, I have implemented my
Linux box as a
    router for my network (installed with
rc.firewall-2.4).also acts
    as DNS forwarder (forwards requests to 10.1.1.1).

  * I have a subnet inside (10.0.0.0).my Linux box
acts as a gateway
    for these computers.

What I want is.....

   Connect a computer from 10.0.0.0 network to connect
computers at
   10.1.0.0 network.

Please tell me what are the rules should be added to
rc.firewall-2.4
file to accomplish this.

Thanks for time

Regards,

Saravanan.V

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

Re: NAT problem

[Antony Stone]

On Monday 21 October 2002 2:04 pm, saravanan sakthi wrote:

>   Here is my sinario...

 [ Large Ascii-art diagram snipped for brevity ]

This network setup simply will not work sensibly.

You have the following networks connected to each other:

10.1.1.0/16
10.1.11.0/16
10.1.9.0/16
10.1.12.0/16
10.0.0.0/8

There is no sane way you can get the network addresses, all with a /16 
netmask, to communicate.   Every one of the /16 networks has 10.1.0.0 as its 
network address, and 10.1.255.255 as its broadcast address.   Yoou routers 
simply will not know what to do.

Also, the final network you listed, 10.0.0.0/8, covers all the other networks 
combined - I don't know whether to say this is just as bad as the first four, 
or even worse:-)

To summarise - before you start playing around with netfilter and trying to 
control what *isn't* allowed through your routers (after all, that's what 
netfilter is - a packet filter which doesn't allow some packets through which 
otherwise would get routed), please create a network setup where you have 
differen subnets on each segment, and it is possible to create some routing 
tables which will work.

As a first suggestion, changing all your netmasks to /24 would appear to do 
the trick.

Antony.

-- 

Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

NAT Problem

[Morgan]

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

Hello.
 
I have a question about NAT.
 
I have a client and three servers.
 
One server which I do a remote connect to, and two application servers.
 
Client IP =                            1.2.3.4
Remote con server IP =          1.2.3.5
App Server 1 IP =                  1.2.3.6
App Server 2 IP =                  1.2.3.7
 
I have the following problem.
When I have connected to the Remote con Server I need to be able to
access App Server 1 port 5555 by entering the name of App Server 2 port
5555. (Why is long story)
 
So if I access Remote Con Server and give the command: AppName
AppServer2 -p 5555 I should really access AppServer1 -p 5555
 
 
I figure this can be done with some NATing.
 
Anyone who have any suggestions?
 
 
 
Thanks
Morgan
 

[-- Attachment #2: Type: text/html, Size: 8700 bytes --]

Nat PROBLEM

[lcef]

Hello netfilter,

  Hello:
  I have a problem with IP translation.
  I have 2 machines, with DSL conection.
  First machine have eth0 (213.23.xxx.xxx) and second machine with a
  second ethernet named eth1(192.168.2.1).
  I have a webcam in the second machine(192.168.1.21 eth1)and i want
  who any people go to first machine (213.23.xxx.xxx)can look the
  webcam who are installed in de second machine 192.168.2.1:8080.
  In others words when you type http://213.23.xxx.xxx:8080  go to
  192.168.2.1:8080.
  What rules need i to put with IPFILTER?
  Can you help me please.
  Thanks for your time

-- 
Best regards,
 lcef                          mailto:lcef@eb3cef.net

Re: Nat PROBLEM

[Antony Stone]

On Monday 24 June 2002 12:11 pm, lcef wrote:

> Hello netfilter,
>
>   I have 2 machines, with DSL conection.
>   First machine have eth0 (213.23.xxx.xxx) and second machine with a
>   second ethernet named eth1(192.168.2.1).
>   I have a webcam in the second machine(192.168.1.21 eth1)and i want
>   who any people go to first machine (213.23.xxx.xxx)can look the
>   webcam who are installed in de second machine 192.168.2.1:8080.
>   In others words when you type http://213.23.xxx.xxx:8080  go to
>   192.168.2.1:8080.
>   What rules need i to put with IPFILTER?

iptables -A PREROUTING -d 213.23.xxx.xxx -p tcp --dport 8080 -j DNAT --to 
192.168.1.21
iptables -A FORWARD -d 192.168.1.21 -p tcp --dport 8080 -j ACCEPT

 

Antony.

Completely NAT an ISP: A practical possibility?

[Brian Capouch]

I tried to capture the whole message there in the subject :-)

I wonder if the sages on this list might share advice as to whether or 
not it might be practical to maintain a working ISP where ALL client 
machines use private IP addresses, which are then NAT-ted to public IP 
space as necessary by iptables.

I am getting ready to deploy a small ISP, and this is a very attractive 
idea, but when soliciting ideas from various in-the-know folks I have 
consulted opinions seem to vary very widely.

The biggest drawback that has been voiced so far is that many 
peer-to-peer apps would break, but I'm not so sure right now that is bad 
thing.

All advice gratefully considered.

Thanks.

B.

Re: Completely NAT an ISP: A practical possibility?

[Antony Stone]

On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> I wonder if the sages on this list might share advice as to whether or
> not it might be practical to maintain a working ISP where ALL client
> machines use private IP addresses, which are then NAT-ted to public IP
> space as necessary by iptables.
>
> The biggest drawback that has been voiced so far is that many
> peer-to-peer apps would break, but I'm not so sure right now that is bad
> thing.

Some current ISPs already do this, and I guess the popularity with their 
customers varies according to what the customers want to do :-)

I know of 'residential' accounts where the ISP gives you a private address 
and you're dynamically NATted out to the Internet (so there's no possibility 
at all of hosting incoming services), and 'business' accounts where you have 
two-way static SNAT/DNAT, where as you say above some protocols will work and 
some won't.

Technically there's certainly no reason at all why you can't do this; in 
practice it'll come down to the contract you have with your customers, and 
what they can reasonably expect to be able to do with the connection you 
provide.

Just out of interest, how are you proposing to handle bandwidth allocation - 
making sure each customer gets a reasonable bandwidth without hogging the 
whole link ?

 

Antony.

Re: Completely NAT an ISP: A practical possibility?

[Nick Drage]

On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:

> > I wonder if the sages on this list might share advice as to whether or
> > not it might be practical to maintain a working ISP where ALL client
> > machines use private IP addresses, which are then NAT-ted to public IP
> > space as necessary by iptables.
> >
> > The biggest drawback that has been voiced so far is that many
> > peer-to-peer apps would break, but I'm not so sure right now that is bad
> > thing.
> 
> Some current ISPs already do this, and I guess the popularity with their 
> customers varies according to what the customers want to do :-)

Can you name any ISPs that do this?  I haven't seen it in my limited
experience.

<snip>

-- 
FunkyJesus System Administration Team

Re: Completely NAT an ISP: A practical possibility?

[Sathi]

Hi,
I am Sathi from India.
I have implemented this in my place by providing a connectionn to 100 to 150
customers.

I provide a Local ip address and all will be terminate in a linux box in my
office which is then nated to public ip.

Everything looks fine except MSN voice chat , NETMEETING voice and video and
some other tools used for phone2pc and pc2phone.

Regards,
Sathi

> On Sat, Jun 15, 2002 at 11:33:23PM +0100, Antony Stone wrote:
> > On Saturday 15 June 2002 11:14 pm, Brian Capouch wrote:
>
> > > I wonder if the sages on this list might share advice as to whether or
> > > not it might be practical to maintain a working ISP where ALL client
> > > machines use private IP addresses, which are then NAT-ted to public IP
> > > space as necessary by iptables.
> > >
> > > The biggest drawback that has been voiced so far is that many
> > > peer-to-peer apps would break, but I'm not so sure right now that is
bad
> > > thing.
> >
> > Some current ISPs already do this, and I guess the popularity with their
> > customers varies according to what the customers want to do :-)
>
> Can you name any ISPs that do this?  I haven't seen it in my limited
> experience.
>
> <snip>
>
> --
> FunkyJesus System Administration Team
>
>

nat problem.

[umar]

Hi, 
 
Trying out  a very simple configuration of a firewall here, but having some problems.
The firewall  has two NIC's and have enabled ip forwarding. 

I want the internal machines to connect to the internet,  So have enabled NAT : 
Runing squid - transparent proxy on port 3232. Clients have been onfigured to connect to internet directly. 
eth0 is my external interface.
 
Following are the nat rules conigured on the firewall
 
iptables -t nat -A PREROUTING -i eth0  -p tcp --dport 80 -j REDIRECT --to-port 3232
 
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x ( public IP of the other netwrok card )

I can ping to the gateway ( private IP ) and the other network card havng the public IP , but nothing beyond that, Why ?? 
And my clients are also not able to connect to the internet ?? 
I have tried removing the first rule and disabling squid, so that clients could connect to the intenet directly. 
That also failed, and the result is the same. All the default poilicies of all rules are set to ACCEPT.

Runing rh 7.2 with 2.4.7-10 kernel.

Please help. 

Warm Regards, 
Kumar. 

Re: nat problem.

[Antony Stone]

On Monday 17 June 2002 11:58 am, umar wrote:

> Hi, 
>  
> Trying out  a very simple configuration of a firewall here, but having some
> problems.
 The firewall  has two NIC's and have enabled ip forwarding.
> 
> I want the internal machines to connect to the internet,  So have enabled
> NAT : 
 Runing squid - transparent proxy on port 3232. Clients have been
> onfigured to connect to internet directly. eth0 is my external interface.
>  
> Following are the nat rules conigured on the firewall
>  
> iptables -t nat -A PREROUTING -i eth0  -p tcp --dport 80 -j REDIRECT
> --to-port 3232
 
> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x ( public
> IP of the other netwrok card )
 

What do you mean "IP of the *other* network card" ?

The address here should be the address of eth0.   Tell us if you're using 
something else, and if so what you're using (we don'tneed to know the IP 
address, just where it lives on the network).

 

Antony.

NAT problem

[Tyler Kemp]

Hey,
	I recently installed linux on a spare box I had, in order to share my DSL
connection throughout the house. I've run into a problem with iptables.

Linux distro: Debian Woody
Kernel: 2.4.17
iptables version: 1.2.6a

	Iptables modules are loaded completely, local LAN is setup correctly, and
the windows machine I've been testing the connection with is configured to
use the linux box as it's gateway (no firewall on the windows machine).

Rules I'm using:
#!/bin/sh
#
#   Firewall
#


echo "Setting up Netfilter Firewall"
#flush
iptables -F
iptables -t nat -F

#allow anything already established
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#allow anything new from LAN
iptables -A INPUT -m state --state NEW -i ! ppp0 -j ACCEPT

#drop mySQL
iptables -A INPUT -p tcp --dport 3306 -j REJECT --reject-with tcp-reset

#open ident
#iptables -A INPUT -p tcp --dport 113 -j ACCEPT

#open httpd
#iptables -A INPUT -p tcp --dport 80 -m limit --limit 2/s -j
LOG --log-prefix "Apache "
#iptables -A INPUT -p tcp --dport 80 -j ACCEPT

#open ssh
#iptables -A INPUT -p tcp --dport 22 -m limit --limit 2/s -j
LOG --log-prefix "SSH "
#iptables -A INPUT -p tcp --dport 22 -j ACCEPT

#allow identd
#iptables -A INPUT -p tcp --dport 53 -j ACCEPT

#log specific curious ports before accepting/denying them
iptables -A INPUT -i ppp0 -p tcp --dport 31337 -m limit --limit 2/s -j
LOG --log-prefix "Trojan "
iptables -A INPUT -i ppp0 -p tcp --dport 27374 -m limit --limit 2/s -j
LOG --log-prefix "Trojan "
iptables -A INPUT -i ppp0 -p tcp --dport 12345 -m limit --limit 2/s -j
LOG --log-prefix "Trojan "

#iptables -A INPUT -i ppp0 -p tcp --dport 6666:7000 -m limit --limit 2/s -j
LOG --log-prefix "IRC "
iptables -A INPUT -i ppp0 -p tcp --dport 6346 -m limit --limit 2/s -j
LOG --log-prefix "6346 DoS "

#allow anything out of service range for tcp/udp (ports over 1024)
iptables -A INPUT -p tcp --dport 1024: -j ACCEPT
iptables -A INPUT -p udp --dport 1024: -j ACCEPT

#Log everything else below 1024
iptables -A INPUT -i ppp0 -p tcp -m limit --limit 1/s -j LOG --log-prefix
"DROPPED "
iptables -A INPUT -i ppp0 -p udp -m limit --limit 1/s -j LOG --log-prefix
"DROPPED "
iptables -A INPUT -i ppp0 -p icmp -m limit --limit 1/s -j LOG --log-prefix
"DROPPED "

#drop the rest with devious tcp reset
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -j DROP

#setup NAT
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE


#forward chain

#syn flood limiting
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit
1/s -j ACCEPT


#enable ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

echo "Starting IP Forwarding"


The symptoms:
	The linux box connects properly to my DSL service, and can see the windows
box on the local LAN (windows box can see the linux box aswell). I can
access services on the linux box such as ssh and http, but something is
preventing the windows box from seeing anything on the outside world via the
DSL. Any ideas/solutions?

		Cheers,
			Tyler

Tyler Kemp
----------
tylerk4@sbcglobal.net
tyler@strtok.co.uk
tylerk4@softhome.net

Re: NAT problem

[Antony Stone]

On Thursday 09 May 2002 5:41 am, Tyler Kemp wrote:

> Hey,
> 	I recently installed linux on a spare box I had, in order to share my DSL
> connection throughout the house. I've run into a problem with iptables.
>
> The symptoms:
> 	The linux box connects properly to my DSL service, and can see the windows
> box on the local LAN (windows box can see the linux box aswell). I can
> access services on the linux box such as ssh and http, but something is
> preventing the windows box from seeing anything on the outside world via
> the DSL. Any ideas/solutions?

Yes.   All your rules are in the INPUT chain (except for the stuff labelled 
'syn flood limiting').

The INPUT chain is only for packets going to the firewall itself.

The FORWARD chain is for packets going across the firewall from a machine on 
one side to a machine on the other.

 

Antony.