Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[voip-puzzle]

I'm having problems configuring the DFL-800 to meet our voip requirements.  Essentially we need ports 5060 / 5090 / 9000-9015 to be used but without any port translation. 

The steps we have used so far are as follows:

1) Each port has been added as a tcp/udp service and then the services combined into a service group
2) An IP rule folder has then been created for VOIP with a SAT rule and an allow rule for the service group.

This works to a certain extent but the fact the the outbound traffic is still having the ports translated is causing issues with voip and we need to stop the port translation.

I've seen other voip posts in the forum have not been able to resolve my problem by reading them, any help would be greatly appreciated.

Thanks

[Fatman]

If the problem is outbound traffic lets take a look at your outbound rules...

Given you need to write a port forward to get the traffic to your SIP device we obviously need to NAT the outbound traffic.

What exactly is the firewall doing to the outbound traffic?

[voip-puzzle]

Thanks for the prompt reply

It appears the outbound traffic is being translated to other ports.  This is being highlighted by the firewall checking utility for the phone system we are using.  For example it reports:

TCP SIP Port is set to 5060. Response received WITH TRANSLATION 57972::5060.
TCP TUNNEL Port is set to 5090. Response received WITH TRANSLATION 49623::5090.
UDP RTP Port 9000. Response received WITH TRANSLATION 14820::9000.
UDP RTP Port 9001. Response received WITH TRANSLATION 32353::9001.

This seems to suggest the connection attempt from port 5060 was translated to 57972 when the connection was made to the remote ip. 

Hope this helps.

[Fatman]

Unless you have some rules written to make such things happen there would be no port manipulation by this firewall.

I quick google turned up some others having such problems (some of which with devices which couldn't possibly translate outbound traffic).

At this point my main question is what do you see if you run a packet capture?

[voip-puzzle]

We have run a packet capture on the pc running the phone system and the packets are correct at the point they leave the pc.

We have installed the same phone system with other firewalls without issue, but having said this we installed the firewalls as well with 'clean' configs out of the box so we may have missed something that was already configured on the DFL800.

We have not tried examining the packets as they leave the firewall, can this be done with debug logging?

[Fatman]

You can turn logging on for your outbound IP Rules and that would show log entries for the opening and closing of every session.

That said a real packet capture would be more informative as there we can compare what we should be getting and what we are getting bit for bit.

[voip-puzzle]

Thanks, just been looking at the logging on the firewall and it does seem to suggest that port is not being translated but that contradicts what the service sees at the other end, for example the firewall reports:

2009-09-08 19:09:58 Notice RULE 6000005 intern_access UDP lan 192.168.44.9 75.101.138.128 9000 3478 ip_verified_access access_allow  ipdatalen=36 udptotlen=36 

While the voip test routine at the other end reports:

UDP RTP Port 9000. Response received WITH TRANSLATION 30161::9000.

We have spoken to the vendor of the phone system and they assure us that the test routine will report the port the communication was received on and if it states it was translated then this will have happened, but of course this contradicts the firewall.

The trouble is we need to capture the packet after it leaves the firewall or at the destination to be definitive, can you suggest an easy way of doing this?

[Fatman]

A hub or switch that supports port mirroring on the WAN port of the firewall is the easy bet in my book.

[voip-puzzle]

Thanks for the suggestion.  We have managed to confirm the ports are being translated by making test connections to another remote ip address and watching the inbound connections on the remote firewall.

For example:

voip sever 192.168.1.9
wan w.x.y.z
remote service a.b.c.d

connection from voip server 192.168.1.9 port 5060 to remote ip a.b.c.d port 3478
dfl-800 logs connection from 192.168.1.9 port 5060 to a.b.c.d port 3478
remote firewall receives connection from w.x.y.z port 59264

So this confirms the problem, even though the dfl-800 does not log the outbound port being translated it is being translated as the remote service receives a connection from port 59264 and not port 5060 which is the issue we need to resolve.

We've run out of ideas to resolve this issue

Thanks

[voip-puzzle]

Just got another update, as we're uk based we have been in touch with support about this issue for several weeks via email which has been a very slow process without any help or suggestions.

As a result we posted on this forum yesterday and got more responses in 1 day then we did from the uk team in three weeks but I have just called them again to chase up and they have now stated that the dfl-800 does not support static mapping / full cone NAT and we will not therefore be able to achieve the required setup

Can you confirm if you agree with this statement??

[Fatman]

Sorry for the delay, I am looking into this case.  I had misinterpreted your request at first, though I think I have a handle on the real issue now.