Some packets are not translated



  • My setup

    pfSense 1.2.3-RELEASE

    WAN interface (fxp0) with interface public IP 12.34.56.78, virtual IP 12.34.56.79
    LAN interface (vlan0 on em0) with IP 192.168.1.1/24
    OPT1 interface (vlan1 on em0) with IP 192.168.14.1/24
    OPT2 interface (vlan2 on em0) with IP 192.168.6.1/24

    LAN interface is connected to a network which has an internal router 192.168.1.100, and behind it another internal network 172.26.0.0/16. Corresponding static route is defined in pfSense.

    I have set up manual outbound NAT on WAN interface so that networks 192.168.1.0/24, 192.168.6.0/24 and 172.26.0.0/16 are translated to WAN interface IP, network 192.168.14.0/24 is translated to WAN virtual IP.

    I'm seeing that some packets going out the WAN interface are not translated, i.e. pfSense is sending out packets with src addresses from the internal network range. This doesn't seem to happen with all packets. For example, I'm creating a ssh session to another external host from my machine in the internal network. The packet filter on external host is set to drop and log all packets whose src address is internal RFC1918 address. I see some dropped packets with my internal src IP in the filter logs of external host, but I can get connected, which means that the connection is ultimately made with my external IP

    Running tcpdump on external interface of my pfSense box I see a lot of packets like this, with internal src IPs:

    # tcpdump -i fxp0 -n -e -tttt host 172.26
    2010-03-05 11:39:56.049090 00:0a:e4:01:38:f1 > 00:08:e3:7e:b9:ff, ethertype IPv4 (0x0800), length 54: 172.26.6.11.1615 > 65.54.189.178.1863: . ack 3062512730 win 0
    2010-03-05 11:39:56.049129 00:0a:e4:01:38:f1 > 00:08:e3:7e:b9:ff, ethertype IPv4 (0x0800), length 54: 172.26.1.8.4886 > 94.75.250.76.443: . ack 3074396724 win 0
    
    

    But I also see a lot more of packets with external src IP as expected. So it's not that translation is not working altogether, it's just that some packets are not getting translated.



  • I still haven't been able to figure out what's going on. Am I really the only one experiencing this? I rebooted my pfSense box during the weekend, but this made no difference.

    I looked at the existing NAT rules with pfctl -sn and they look like this:

    nat on fxp0 inet from 192.168.1.0/24 to any -> (fxp0) port 1024:65535 round-robin
    nat on fxp0 inet from 172.26.0.0/16 to any -> (fxp0) port 1024:65535 round-robin
    nat on fxp0 inet from 192.168.6.0/24 to any -> (fxp0) port 1024:65535 round-robin
    nat on fxp0 inet from 192.168.14.0/24 to any -> 12.34.56.79 port 1024:65535
    

    What is the meaning of "port 1024:65535" and "round-robin" in above definitions? I can't see these things in nat rule syntax as described at http://www.openbsd.org/faq/pf/nat.html



  • Two more things that I noticed.

    1. The untranslated packets always have 'length 54' and 'win 0' in tcpdump output. Source and destination addresses are variable.
    2. Problem exists only with packets coming from LAN interface (vlan0), but not with packets coming from OPT1 or OPT2 interface (vlan1 or vlan2).

    Maybe someone knows what to think of this - I sure don't.



  • The port range tells pf what range of port numbers to NAT to.  I believe the round-robin is moot in this case (I think it is used to round robin through multiple IP addresses if present, for a load balancing scheme or some such?)  Sorry I don't have input as to the issue you are seeing though.



  • I'm starting to think this is some kind of weird packet fragmentation/MTU mismatch issue.

    As I noted earlier, the nontranslated packets are always 54 bytes long.

    Ethernet frame size=1514 bytes.

    MTU on the vlan0 interface=1500 bytes, giving a TCP MSS of 1460

    1460+54=1514…



  • Hi vatson!

    I've experienced the same that you describe:

    <http: forum.pfsense.org="" index.php="" topic,19208.msg98830.html#msg98830="">Nobody (except you and me) has discovered this before?

    My release is 1.2.2 and the issue continues the same way.

    In my case, the interface in not the LAN one, but one of the OPTn.

    Regards: Paco.-</http:>


Log in to reply