[App_rpt-users] BIG registration problem this morning

Bryan Fields Bryan at bryanfields.net
Mon Aug 13 06:34:08 UTC 2018


On 8/12/18 11:06 PM, Danny K5CG wrote:
> I'm running pfSense and I "could" setup a static port for the outbound NAT
> but since when does the source port ever match the destination port, for
> any protocol? I'm not touching it.

Most VoIP-ish protocols require what's known as "full cone NAT".  This is
where a router/packet mangler takes an external address and port/protocol and
maps it to the same internal port/protocol in a bidirectional fashion.  When
you "port forward" on most consumer grade routers, it creates a full cone NAT.
Many consumer routers do full-cone NAT for dynamic protocols as well.  Due to
IAX being UDP based (stateless) most NAT implementations will automatically
map this in both directions, for all external hosts.

Simply put if your internal device uses port 5000 it will map as follows:

Outbound direction:
IntIP:srcPort-5000  > NAT device >  ExtSrcIP:srcPort-5000 > ExtDstIP:dst-5000

If the router is doing full-cone NAT (most consumer grade routers do this by
default it will add a mapping like this automagically:

Inbound direction:
IntSrcIP:dst5000  < NAT device <  *:5000

This has the distinct advantage of just working behind NAT for certain
realtime protocols without needing an application aware gateway.  This does
however open up the world inbound if you know this, so most higher end
firewalls don't do this, and will lock down that inbound connection to what
the source has talked to externally.  This requires some memory and connection
tracking of UDP.

When you configure outbound PAT or port address translation which is a many to
one, the router will dynamically remap your source ports on the external
device so they don't overlap with other users on your network.  This will map
the local source port of say 4569 to some random high value, say 75401.  Your
packet will now go out and talk to the external user as your
extIP:src75401:dst4569.  With IAX, the external user will now be able to talk
back to you as there's a mapping on your router of externalHostIP:dst75401 to
your internalIP:dst4569, but it's only valid for that one external Host of the
IAX server.  No other servers can use externalIP:dst75401 to talk to your IAX
server as the external srcIP is different.

The way to solve this is to statically map extIP:dst4569 to intIP:dst4569 and
ensure intIP:4569 to extIP: is not mangled but allowed to pass to extIP:4569.
SIP solves this via application layer gateways (ALG) on firewalls, same as FTP.

This will make a full cone NAT and is what's needed for IAX to work.  Right
now you have a unidirectional mapping from ext to int, but not int to ext.

Further reading:
https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation
> 46679*CLI> iax2 show registry Host                  dnsmgr  Username
> Perceived             Refresh  State 44.98.254.145:4569    Y       46679
> 47.187.195.172:29961       60  Auth. Sent
> 
> 4569 is what's set on the portal for my node. 29961 appears to be what is
> recorded on the server from my registration.

Yea, that was a dirty hack.

> The portal port needs to be used or there has to be a way to set the port
> in rpt.conf to have that communicated to the registration server. Relying
> on the source port (which can be anything) is not a good idea.

95% of the time it works every time.  Your have a corner case, and as you have
a decent packet filter (pfsense) it's easily configured to work for this.
Based on this doc,  https://www.3cx.com/docs/pfsense-firewall/ you will need
to enable "Port Preservation" for your IAX server.
> Next steps?

Turn on Port Preservation and report back.

Thanks,

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net



More information about the App_rpt-users mailing list