CORRECTION: Should be One-to-One Bi-Directional Static NAT. Some firewalls perform NAT Pooling…
Firewalls; love them, hate them. They are a necessary evil and the bane of pretty much every Lync/Skype Deployment Specialist since the beginning of UC. Used to be we just needed a two-way NAT, then the terminology became Static NAT or SNAT, which now we can’t use thank you very much F5, so now the landed terminology that seems to have stuck which no one has usurped is “Bi-directional Static Network Address Translation”, BDSNAT or BSNAT… ok, we’ll stick with Bi-directional Static NAT.
It’s hard keeping up with all the different firewalls so I try to keep the language universal, and yes it seems that just about every firewall product out there has their own language. Sometimes it’s as similar as Canadian English and American English, same but subtle differences. Or as different as Oxford English and Urban English (yup, look it up, Urban). What ever the language, we need to keep our terminology as universal as possible, and some firewall admins still struggle.
Now you get past that struggle, and a firmware update comes along for the firewall… Recent case in point.
A client was going through a ISP requested IP Address Change to a new block. During this outage it was thought to be a good idea to update the firmware on the firewall, in this case it was a SonicWALL NSA running firmware version 188.8.131.52 and was upgraded to 184.108.40.206. For the first 4 days, everything seemed fine, but Friday morning things went sideways. Outbound PSTN calls via their ThinkTel SIP trunks, failed to have Outbound Audio. Inbound Audio was fine, as well as Inbound Calls were fine as well. Additionally, if the Caller put the call on hold and then Resumed, Outbound audio started working.
After much trouble shooting with the good folk and ThinkTel, and burning my eyes out looking at Wireshark (literally, had to go to the optometrist), I was having a tough time aligning calls up, ports weren’t making sense, thought the times zones were buggered, it was very frustrating.
I decided to do a top-to-bottom review with the FW Admin of the SonicWALL. Asking every question about what is working and how, what does this checkbox do, yadda, yadda, yadda. Border line embarrassing actually, but so often works. That’s how we came across the setting for “Disable Source Port Remap” in this environment. Firmware version 220.127.116.11 added a new feature for NAT’s, the ability to “Disable Source Port Remap”.
After reflecting on the change and resolution we discovered, I was able to go back and see that I did in fact have the same network wire traces, and is now very obvious what was going on. Sometimes I’m not losing my mind, I’m just not comprehending what I’m seeing and I thought I was in error.
After getting my Wireshark all tuned up to display time and not relative time, and a few other odd and ends which I should post something about, assuming I can remember all of what I did… Anyway, line for line, you can see the port progression, and it was actually this particular trace that flagged me to look at the ports, cause why on earth was there RTP traffic coming from ThinkTel to the Mediation server on port 3227 there, and why can’t I find it in my Mediation trace…
This will be something lodged into my brain for a while I hope. I also do not think that this will be isolated to SonicWALL firewalls. I expect one might also see this kind of behavior with SIP ALG, SIP Inspect, and what ever else might mess with SIP traffic at a Network or Application Layer. The SIP packets themselves contain the port negotiation required for RTP connectivity, last thing we need is a firewall trying to do its own thing.
Feel free to add a comment if you seen similar “port remapping” on different firewalls, and if it was related to some application layer setting. I always thought SIP ALG was more about the Verbs being used, curious now if it also messes with ports too.