[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: desperate! can't get port forwarding to work on debian testing 2.6.15

[Short answer before I have to go out for a while]

Mike Garey a écrit :
dev is a freebsd machine and has the following config:

[11:04AM][mike@dev]% ifconfig
        inet6 fe80::215:f2ff:fe04:9bd0%em0 prefixlen 64 scopeid 0x1
        inet netmask 0xffffff00 broadcast
        ether 00:15:f2:04:9b:d0
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        inet6 fe80::20d:88ff:fe4e:1f09%vr0 prefixlen 64 scopeid 0x2
        inet netmask 0xfffffff8 broadcast
        ether 00:0d:88:4e:1f:09
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

and the routing table is as follows:

[11:21AM][mike@dev]% netstat -r -n -f inet
Routing tables

Destination        Gateway            Flags    Refs      Use  Netif Expire
default         UGS         0      272    vr0

OK, I think I got it.

now, both dev and asterisk machines have their internal NIC connected
to the same switch.

I guess you mean "the same pair of switches" ?

Maybe your BSD box has no default route to the NAT gateway, or it has a
firewall filtering out packets originated from outside the internal network.

as can be seen from the BSD routing table for dev, the firewall is set
to allow everything, and it does have a default route to the NAT
(      00:11:2f:38:52:8d  UHLW        1    17540   em0)

That's an explicit route, not a "default" route (route to
IMHO, the problem is that the default route sets the default gateway instead of the NAT box internal address. So here's what I think that happens : 1) The NAT box receives a request packet from the internet on its external interface. 2) The NAT box translates the destination address and forwards it to the internal server. 3) The server receives the packet on its internal interface em0. So far so good. 4) The server replies. It looks up its routing table how to reach the packet source address. This address is not covered by any specific route, so the default route is used. So the reply is sent to the instead of the NAT box as it should, and its source address is not un-NATed properly. The packet may make its way back to the client, but it has the wrong source address, the client does not recognize it as a reply to its request.

If I'm right, you need to make sure that the reply packet from the server goes back to the NAT box so its source address is un-NATed properly. One way to do this is to masquerade the source address in the NAT box unsing SNAT or MASQUERADE. But you lose the real source address information on the server :

iptables -t nat -A POSTROUTING -o $INTIF -d $PORTFWIP \
  -p tcp --dport 8090 -j SNAT --to $INTIP

Other ways may include advanced routing on the server to send the reply packets back to the NAT box. But I don't know *BSD, so I can't help you on this.

Reply to: