# UDP redirect suddenly stopped working!



## arcivanov (May 19, 2012)

I'm having the weirdest problem. The rules have been working for several years. All of a sudden my PBX behind NAT stops receiving incoming calls. I got to my firewall to find that the incoming UDP packets no longer match.

Here's the skinny:

```
fw1# tcpdump -i pflog0 -s 16384 -ttt -e -n host sip.telphin.com
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 16384 bytes
00:00:00.000000 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000246 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:00.465232 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000874 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:00.999174 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000873 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:01.999097 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000872 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:03.999194 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000995 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:03.999068 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000871 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:03.999448 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000864 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:03.998944 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000872 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:03.999073 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000991 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
00:00:03.999069 rule 1..16777216/0(match): block in on em0: 213.170.92.166.5068 > 98.229.10.142.5060: SIP, length: 1472
00:00:00.000994 rule 1..16777216/0(match): block in on em0: 213.170.92.166 > 98.229.10.142: udp
```

Rules (excerpts):


```
@4 scrub on em0 all random-id min-ttl 254 max-mss 1452 reassemble tcp fragment reassemble
@9 nat on em0 inet proto udp from 192.168.157.42 port = sip to any -> (em0) round-robin static-port
@8 rdr on em0 inet proto udp from any to (em0:*) port = sip tag SIP -> 192.168.157.42
@0 pass log (all) quick all flags S/SA keep state tagged SIP
```

In fact I completely removed all filtering (pass quick all) and the packets still did not match rdr.

I suspect the fragmentation is a culprit, i.e. provider upgraded their backend, packet baseline size increased and rules started failing.

What I can't figure out is what to do about it. Any ideas?


----------



## arcivanov (May 19, 2012)

This behavior is observed with both 8.2-p7 and 9.0-p1.


----------



## arcivanov (May 23, 2012)

UPDATE: 

[CMD=]ifconfig em0 -txcsum -rxcsum -tso[/CMD] 

does not seem to help in the slightest.


----------

