Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
Because of this "Remember that static-port means you can't have two
machines behind the same NAT using the same source port and destination.",
you should instead probably use "binat-to" as a good practice.
This will help force you to not be able to accidentally reuse the same
public IP for another internal server.
SIP uses a lot of ports, and so it really does need its own public IP with
a one to one mapping to the private IP.
If you have remote SIP phone clients that need to run over the gateway too
(not just a SIP trunk), the following helped us keep client
registrations alive;
set timeout { udp.first 1200, udp.single 600, udp.multiple 1800 }
Cheers, Andy.
On Thu, Jun 9, 2016 at 11:40 PM, Stuart Henderson
wrote:
> On 2016-06-09, Markus Wernig wrote:
> > On 06/09/2016 08:03 PM, Bryan Vyhmeister wrote:
> >> On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote:
> >>> Short question:
> >>> How do I prevent pf from changing the source port of outgoing natted
> udp
> >>> packets?
> >>
> >> Did you look at static-port in pf.conf(5)?
> >
> > Argh! I had overlooked that. Shame. Works now.
>
> Remember that static-port means you can't have two machines behind
> the same NAT using the same source port and destination.
>
> If it's OK to change the source port as long as it ends up within
> a certain port range, you can do something like 'nat-to $address port
> 8000:9000'.
>
>
--
*Download our latest free guide here
Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
On 2016-06-09, Markus Wernig wrote: > On 06/09/2016 08:03 PM, Bryan Vyhmeister wrote: >> On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote: >>> Short question: >>> How do I prevent pf from changing the source port of outgoing natted udp >>> packets? >> >> Did you look at static-port in pf.conf(5)? > > Argh! I had overlooked that. Shame. Works now. Remember that static-port means you can't have two machines behind the same NAT using the same source port and destination. If it's OK to change the source port as long as it ends up within a certain port range, you can do something like 'nat-to $address port 8000:9000'.
Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
On 06/09/2016 08:03 PM, Bryan Vyhmeister wrote: > On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote: >> Short question: >> How do I prevent pf from changing the source port of outgoing natted udp >> packets? > > Did you look at static-port in pf.conf(5)? Argh! I had overlooked that. Shame. Works now. Thanks! /m
Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote: > Short question: > How do I prevent pf from changing the source port of outgoing > natted udp > packets? Did you look at static-port in pf.conf(5)? Bryan
Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
> On 09/06/2016, at 18:48, Markus Wernig wrote:
>
> Hi all
>
> I have a strange behaviour in pf on 5.9-stable:
>
> A system (asterisk) behind the gateway is receiving and replying to udp
> streams (RTP). The connection parameters (src/dst ip/port) are set up
> before (STUN and SIP), so both systems "know" where to send to.
>
> The gateway does NAT (rdr-to in, nat-to out) for the system. But while
> incoming packets are forwarded with source and destination port
> unchanged, the source port on the outgoing packets is changed (to
> something in the >5 range). This breaks the connection, as the
> external system (resp. the firewall it is behind) expects the packets to
> have the original dst port as src port.
>
> The same happens when the system starts a udp stream on its own - the
> source port gets rewritten. Also the UDP checksum appears to be wrong
> after the NAT.
>
>
> Short question:
> How do I prevent pf from changing the source port of outgoing natted udp
> packets?
Add "static-port" to the match rule
>
> Long question:
>
> tcpdump:
>
> $int_if:
> 18:40:21.392468 $int_server_ip.10442 > $external_system.5012: [udp sum
> ok] udp 32 (DF) (ttl 64, id 64912, len 60)
> 18:40:21.396091 $external_system.5012 > $int_server_ip.10442: [bad udp
> cksum a9e7! -> 316d] udp 32 (ttl 115, id 9052, len 60)
> 18:40:21.413332 $int_server_ip.10442 > $external_system.5012: [udp sum
> ok] udp 32 (DF) (ttl 64, id 64916, len 60)
> 18:40:21.415143 $external_system.5012 > $int_server_ip.10442: [bad udp
> cksum a9e7! -> 7036] udp 32 (ttl 115, id 9053, len 60)
> ...
>
> $ext_if:
> 18:40:21.392510 $sext_server_ip.51049 > $external_system.5012: [bad udp
> cksum 528b! -> e3da] udp 32 (ttl 63, id 16487, len 60)
> 18:40:21.395975 $external_system.5012 > $sext_server_ip.10442: [udp sum
> ok] udp 32 (ttl 116, id 9052, len 60) <--This is a "new" incoming stream
>
> 18:40:21.413377 $sext_server_ip.51049 > $external_system.5012: [bad udp
> cksum 528b! -> 53d8] udp 32 (ttl 63, id 30449, len 60)
> 18:40:21.415089 $external_system.5012 > $sext_server_ip.10442: [udp sum
> ok] udp 32 (ttl 116, id 9053, len 60)
> ...
>
> The problem seems to be that the internal system tells the external one
> about the source port (10442) it should connect to (via SIP), and as
> last step sends a packet from that port (plus in-protocol info, I
> assume). But pf changes that source port on that outgoing packet (to
> 51049), and keeps doing so for all following packets, while the external
> system sticks to the protocol and sends its traffic to 10442.
>
> So it looks like pf can't distinguish between what it sees as "follow
> up" packets to the first outgoing packet (18:40:21.392468) and the reply
> packets to the "incoming" stream.
>
> The connection breaks because the firewall the $external_system is
> behind expects replies to the packets send to 10442 to come back from
> that port.
>
> All of this wouldn't happen if the source port hadn't been changed to
51049.
>
> So: is there any way of preventing this behaviour? I didn't find
> anything in pf.conf(5) or elsewhere ...
>
> Thx for any insight, folks
>
> /markus
>
> PS:
> These are the rules in question:
>
> match in from any to $ext_server_ip rdr-to $int_server_ip
>
> match out from $int_server_ip to any nat-to $ext_server_ip
>
> pass log quick on { $ext_if, $int_if } inet proto udp from any to
> $int_server_ip port { >< 11001 } label "RTP IN -- ACCEPT "
>
> pass log quick on { $ext_if, $int_if } inet proto udp from
> $int_server_ip to any port { >= 1024 } label "UDP HIGH OUT -- ACCEPT "
pf changes port on udp nat-to and rdr-to reply packets (RTP stream)
Hi all
I have a strange behaviour in pf on 5.9-stable:
A system (asterisk) behind the gateway is receiving and replying to udp
streams (RTP). The connection parameters (src/dst ip/port) are set up
before (STUN and SIP), so both systems "know" where to send to.
The gateway does NAT (rdr-to in, nat-to out) for the system. But while
incoming packets are forwarded with source and destination port
unchanged, the source port on the outgoing packets is changed (to
something in the >5 range). This breaks the connection, as the
external system (resp. the firewall it is behind) expects the packets to
have the original dst port as src port.
The same happens when the system starts a udp stream on its own - the
source port gets rewritten. Also the UDP checksum appears to be wrong
after the NAT.
Short question:
How do I prevent pf from changing the source port of outgoing natted udp
packets?
Long question:
tcpdump:
$int_if:
18:40:21.392468 $int_server_ip.10442 > $external_system.5012: [udp sum
ok] udp 32 (DF) (ttl 64, id 64912, len 60)
18:40:21.396091 $external_system.5012 > $int_server_ip.10442: [bad udp
cksum a9e7! -> 316d] udp 32 (ttl 115, id 9052, len 60)
18:40:21.413332 $int_server_ip.10442 > $external_system.5012: [udp sum
ok] udp 32 (DF) (ttl 64, id 64916, len 60)
18:40:21.415143 $external_system.5012 > $int_server_ip.10442: [bad udp
cksum a9e7! -> 7036] udp 32 (ttl 115, id 9053, len 60)
...
$ext_if:
18:40:21.392510 $sext_server_ip.51049 > $external_system.5012: [bad udp
cksum 528b! -> e3da] udp 32 (ttl 63, id 16487, len 60)
18:40:21.395975 $external_system.5012 > $sext_server_ip.10442: [udp sum
ok] udp 32 (ttl 116, id 9052, len 60) <--This is a "new" incoming stream
18:40:21.413377 $sext_server_ip.51049 > $external_system.5012: [bad udp
cksum 528b! -> 53d8] udp 32 (ttl 63, id 30449, len 60)
18:40:21.415089 $external_system.5012 > $sext_server_ip.10442: [udp sum
ok] udp 32 (ttl 116, id 9053, len 60)
...
The problem seems to be that the internal system tells the external one
about the source port (10442) it should connect to (via SIP), and as
last step sends a packet from that port (plus in-protocol info, I
assume). But pf changes that source port on that outgoing packet (to
51049), and keeps doing so for all following packets, while the external
system sticks to the protocol and sends its traffic to 10442.
So it looks like pf can't distinguish between what it sees as "follow
up" packets to the first outgoing packet (18:40:21.392468) and the reply
packets to the "incoming" stream.
The connection breaks because the firewall the $external_system is
behind expects replies to the packets send to 10442 to come back from
that port.
All of this wouldn't happen if the source port hadn't been changed to 51049.
So: is there any way of preventing this behaviour? I didn't find
anything in pf.conf(5) or elsewhere ...
Thx for any insight, folks
/markus
PS:
These are the rules in question:
match in from any to $ext_server_ip rdr-to $int_server_ip
match out from $int_server_ip to any nat-to $ext_server_ip
pass log quick on { $ext_if, $int_if } inet proto udp from any to
$int_server_ip port { >< 11001 } label "RTP IN -- ACCEPT "
pass log quick on { $ext_if, $int_if } inet proto udp from
$int_server_ip to any port { >= 1024 } label "UDP HIGH OUT -- ACCEPT "
