Issue with NAT+Port Redirect (PAT)
-
Just a guess, but the source port is probably not 5060.
Do source address any source port any. Then, after you see what the traffic really is, if you can limit it further, go for it.
-
Just a guess, but the source port is probably not 5060.
Do source address any source port any. Then, after you see what the traffic really is, if you can limit it further, go for it.
Source is 5060 packet capture confirms and this is not standard web traffic coming into the firewall - think of the setup as one giant LAN.
I also can't redirect all (any) traffic from 10.114.141.10 to 5062 because that would most likely mess with RTP streams needed for VOIP calls.
-
It will only match traffic with a dest port of 5060.
-
-
Fix it yourself I guess.
-
What you're doing is correct to match that traffic, if it's coming in on the ACWAN interface.
Usually you want source port any, though SIP hard phones tend to set the source and dest ports to 5060. It'd work the same setting the source port to any.
You mentioned "one giant LAN", which makes me wonder if that's a 10.0.0.0/8 network. In that case, you'll also need source NAT so the PBX replies back to the firewall, and it re-translates the traffic back to the original port.
This is highly likely to break things on the VoIP side when directing traffic like that. I'd recommend an alternate approach so you don't have to do such things. It'll work fine from a firewall perspective to do so, but there are so many inherent complications in doing things like that with `VoIP that I have my doubts it'll work for the phones and/or PBX.
-
@cmb:
What you're doing is correct to match that traffic, if it's coming in on the ACWAN interface.
Usually you want source port any, though SIP hard phones tend to set the source and dest ports to 5060. It'd work the same setting the source port to any.
You mentioned "one giant LAN", which makes me wonder if that's a 10.0.0.0/8 network. In that case, you'll also need source NAT so the PBX replies back to the firewall, and it re-translates the traffic back to the original port.
This is highly likely to break things on the VoIP side when directing traffic like that. I'd recommend an alternate approach so you don't have to do such things. It'll work fine from a firewall perspective to do so, but there are so many inherent complications in doing things like that with `VoIP that I have my doubts it'll work for the phones and/or PBX.
We have several sites which use 10.10.0.0/16 10.1.0.0/16 10.0.0.0/16 10.100.0.0/16 so yes technically you could call our office sites a big 10.0.0.0/8 network however I don't use any /8 notation when doing routing as it would break ALOT of things.
10.114.141.0/24 is the network where SIP traffic is coming from which is at our providers datacenter - specifically SIP Traffic comes from 10.114.141.10 on port 5060 (as mentioned before)
I'm unaware of any other addresses on this particular /24 network.To make this simpler lets ignore all other sites except for our HQ which is 10.1.0.0/16.
On the HQ Firewall is ACWAN interface which links to our companies private WAN network.Inside this network sits the SIP Server 10.114.141.10 - The SIP trunk is statically assigned and sends all SIP traffic directly to address 10.1.1.19 over port 5060.
I need the HQ Firewall to do a Port Translation on this traffic as it passes over the interface ACWAN so that when it sends it on to 10.1.1.19 via the LAN interface it is sent over port 5062.As far as traffic going back out from 10.1.1.19 to 10.114.141.10 this is handled by the PBX itself so I don't need to do anything with the traffic that is sent back.
-
So the destination is on a different interface from the source? That's the part that wasn't clear, whether you were routing back out the same NIC (which has the return routing complications I mentioned).
Assuming that is the case, what do your states look like on that traffic? Diag>States, filter on the source or dest IP.
-
udp 10.1.1.19:5060 <- 10.114.141.10:5060 MULTIPLE:MULTIPLE
udp 10.114.141.10:5060 -> 10.1.1.19:5060 MULTIPLE:MULTIPLE -
That's all there is? Nothing being NATed there, which means your port forward isn't matching the traffic. Given the source and destination is fine, maybe it's on the wrong NIC? Needs to be on the source interface of the traffic.
