nat problem
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
Quoted 3 lines · Frans Luteijn
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.
Quoted 26 lines · Antony Stone
Quoted 4 lines · Frans Luteijn
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?Quoted 1 line
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.
Signature · 6 lines
"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.Antony Stone schreef:
Quoted 8 lines · Frans Luteijn
Quoted 4 lines
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:
Quoted 8 lines
Quoted 8 lines · Frans Luteijn
Quoted 4 lines
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.
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
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.
Quoted 9 lines
Quoted 8 lines
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.
Quoted 7 lines
--
"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
Quoted 7 lines · Frans Luteijn
Antony Stone schreef:
Quoted 6 lines · Frans Luteijn
Quoted 4 lines
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.
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
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)
Quoted 2 lines
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.
Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
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).
Quoted 4 lines
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.
Signature · 7 lines
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.Quoted 13 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
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?
Quoted 5 lines
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.
Antony Stone schreef:
Quoted 17 lines · Frans Luteijn
Quoted 8 lines
Antony Stone schreef:
Quoted 6 lines · Frans Luteijn
Quoted 4 lines
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.
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
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?
Quoted 5 lines
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)?
Quoted 31 lines
Quoted 2 lines
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.
Quoted 10 lines
Quoted 9 lines
Quoted 9 lines
Quoted 1 line
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).Quoted 4 lines
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.
Quoted 8 lines
--
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
Quoted 24 lines · Frans Luteijn
Antony Stone schreef:
Quoted 5 lines
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:
Quoted 8 lines
cat
/proc/net/ip_conntrackI 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=1This 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.
Signature · 6 lines
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.Antony Stone schreef:
Quoted 32 lines · Frans Luteijn
Quoted 31 lines
Antony Stone schreef:
Quoted 5 lines
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_conntrackI 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
Quoted 8 lines
Quoted 2 lines
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.
Quoted 8 lines
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.
Quoted 11 lines
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
Quoted 11 lines · Frans Luteijn
Antony Stone schreef:
Quoted 5 lines
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.
Quoted 10 lines
Quoted 7 lines
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.
Signature · 10 lines
"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.Antony Stone schreef:
Quoted 14 lines · Frans Luteijn
Quoted 8 lines
Antony Stone schreef:
Quoted 5 lines
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.Quoted 4 lines
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.
Quoted 6 lines
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?
Quoted 1 line
(snip)
Quoted 6 lines
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.
Quoted 6 lines
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