UDP forwarding not working 2.2.2

Danonthelan

I'm trying to port forward udp netflow traffic on port 9996 to a box on our local lan. I can see traffic coming in on the wan interface via tcpdump but none coming out the opt1 interface.

The PFsense box is configured to route between our isp conection on vlan 3 to our office machines on vlan 2 (interface LAN, 10.1.0.0/24) and servers on vlan 4 (interface opt1, 10.0.0.0/24). This configuration has been working fine for our tcp forwarding, but not for this udp rule.

The non-working rule is this:

Interface: Wan
Protocol: UDP
Destination type: any
Destination port range: 9996
Redirect target IP: 10.0.0.10
Redirect target port: (other) 9996
NAT reflection:Use system default (system default set to Pure NAT)
Filter rule association: Rule NAT

We have a very similar rule using tcp that works just fine:

Interface: Wan
Protocol: TCP
Destination type: any
Destination port range: 20022
Redirect target IP: 10.0.0.10
Redirect target port: (other) 20022
NAT reflection:Use system default (system default set to Pure NAT)
Filter rule association: Rule NAT

I read that pfsense has problems with UDP reflection, so I'm wondering whether this is even fixable on the current version.

doktornotor

What do you mean, "Destination type: any"??? What's not working? The reflection or the port forward? Testing from where?

Danonthelan

I mean under the destination heading, the type dropdown box is set to any. Rule is in this screenshot. http://i.imgur.com/0NNB1pg.png

What's not working is that traffic is coming in, and traffic is not coming out. I'm not sure if it's due to the reflection as I'm running this in a single nic setup, and the tcp forwards didn't start working until I enabled "Pure NAT" reflection.

Therefore, I think the port forward is failing to work due to the reflection not working. I could be completely off base here, but that's just my working theory.

doktornotor

Yeah, that should be your WAN address, not any. We still do not know where are you testing from and whether the issue is with the port forward (access from WAN) or reflection (access from LAN using WAN IP). Even though I explicitly asked. Sigh.

johnpoz

I can tell you for fact that udp forwarding works just fine with 2.2.2 since I have a box on my network as member of ntp pool, both ipv4 which is forwarded and ipv6 which is allowed. And pool.ntp.org monitors the time on the server – if server is not available, or off by too much, etc.. then its pulled from the pool, so clearly its working - and I can watch all the udp queries to the time server from public and my server sending answers, etc.

So is your issue with reflection or forwarding?

Nat reflection is an abomination int he first place.. There is really never a valid reason to use it - its a crutch for lazy admins if you ask me ;)

Danonthelan

By doktornotor's definition, this would be a problem with port forwarding as I have traffic coming in from the wan, hitting the wan interface, and the packets are not being forwarded to our box on the lan. What I'm not sure of is whether all port forwarded packets count as being reflected since I'm running this with a single nic and routing between vlan interfaces on the pf box as seen in this diagram. http://i.imgur.com/POLPvDb.png

johnpoz

While that is a kind of mess and hairpinning like mad – its not a reflection..

Danonthelan

It's not exactly the prettiest setup, but with only one nic in the box we rigged up what we could. For some reason tcp works with this, but it seems there's something preventing udp from working correctly.

johnpoz

Yeah because a 2nd nic is so HIGH budget ;) Could see how that sort of mess is worth it vs spending like $5 for a 100mbit nic or $10 for a gig nic…

So have you sniffed on the wan and see this udp traffic, and then on the lan interface of pfsense that it actually sent the traffic.

Danonthelan

I've sniffed the traffic on the wan interface and saw the udp traffic, then sniffed the lan interface and saw nothing.

johnpoz

So post up your rules and and your sniffs and lets take a look.

What I can tell you for FACT is udp forwards work just fine in 2.2.2 for me..

So you can see sniff on top is done on wan interface - simple
tcpdump -n -i em0 port 123

then second window in that screenshot is done on lan interface em1
tcpdump -n -i em1 port 123

As you can see the traffic that hits wan is sent to lan ip 192.168.9.40, then traffic back and then sent back to requestor from my 24.13.x.x public IP.

udpworking.png_thumb

natandfwrule.png_thumb

Danonthelan

At around 4:00AM Thursday something happened to the configuration and now I'm seeing an even weirder issue. I cranked up the amount of diffs to keep in config history, but it's a bit late for that. The traffic is flowing from our remote host properly, but there are no rules anywhere for the port forward.

Nothing shows for pfctl -sn | grep 9996, pfctl -sr | grep 9996, or grep 9996 /cf/conf/config.xml, but here's the tcpdumps(w.x.y.z being remote ip and a.b.c.d being our WAN ip):

[2.2.2-RELEASE][admin@pfSense.localdomain]/root: tcpdump -i bge0_vlan3 dst port 9996
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0_vlan3, link-type EN10MB (Ethernet), capture size 65535 bytes
14:06:58.109928 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.110272 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.110768 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.110951 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.111289 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.111784 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.112125 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.112284 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.571766 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464
14:06:58.572108 IP w.x.y.z.37625 > a.b.c.d.9996: UDP, length 1464

[2.2.2-RELEASE][admin@pfSense.localdomain]/root: tcpdump -i bge0_vlan4 dst port 9996
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bge0_vlan4, link-type EN10MB (Ethernet), capture size 65535 bytes
14:07:03.110049 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.110200 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.110541 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.110723 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.111061 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.111402 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.111559 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.111898 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464
14:07:03.112237 IP w.x.y.z.37625 > 10.0.0.10.9996: UDP, length 1464

Here are the states for the port:

bge0_vlan3 udp 10.0.0.10:9996 (a.b.c.d:9996) <- w.x.y.z:37625       NO_TRAFFIC:SINGLE
bge0_vlan4 udp w.x.y.z:37625 -> 10.0.0.10:9996       SINGLE:NO_TRAFFIC

It's "working" now, but if the connection drops I don't think it will start back up again.

EDIT: Yeah, resetting states killed it. I re-added the rule with destination set to WAN address instead of any and it's working now. That's probably all it was.