Firewall not allowing traffic in even thought NAT is open.

[ryhiggin]

I am working on getting certain voip applications working through Wingate. It appears that I have the proper traffic flow for this to work but something in the NAT engine is not working as I understand it should.

On the Activity Pane of the Control Panel I see:

NAT: UDP 10.0.0.204:5060 <-> 166.xxx.xxx.69:5060

But when the traffic tries to come back in it is blocked at the firewall - I see on the firewall tab:

Reason: Port Range
...
Source IP address: 166.xxx.xxx.69 : 5060
Destination IP address: 166.xxx.xxx.70 : 5060
Protocol: UDP
Time-to-live: 128

Is there anything that I am missing that is causing this packet to be stopped by the firewall? I don't want to have to open the firewall manually, shouldn't it leave it open for return traffic on the same IP and port?

Thanks,

Ryan Higgins

[genie]

As far as I can see you had a UDP connection outbound from one of your local machines (10.0.0.204) to 166.x.x.69. At the same time firewall hit reported was from .69 to .70 - and if you do not have anything open on .70, the traffic would be blocked.

[ryhiggin]

Thanks for the quick reply

The traffic sent from the 10.0.0.204 was sent to 166...69 but appears to come from the 166...70 (as this is the outside interface in Wingate) but the responding packets coming back to 16...70 on the same port are getting blocked. In all other firewall scenarios this works fine.

Can I not prop the NAT open by sending out traffic on the appropriate ports?

[genie]

Hmmm... Say, you have this setup:



Client 10.0.0.204 ---> WG y.y.y.y ----> 166.x.x.69

When a packet is NATed, for 166.x.x.69 it appears to come from y.y.y.y, so all the return packets would be sent as 166.x.x.69 --> y.y.y.y and then NAted to the client.

If you have yet another external interface on WG machine, then when it receives a packet from another external machine it does not anything about the connection being opened on y.y.y.y and as a result it drops the inbound packets as fraudulent.

[ryhiggin]

I only have one internal and one external interface/address on the wingate box. This is the packet flow:

(s:source address:port/d:dest address:port)

(s:10.0.0.204:5060/d:166...69:5060) ----> Wingate changes the source address so the packet is (s:166...70:5060/d:166...69:5060)

The corresponding packets flowing in the other direction are:

(s:166...69:5060/d:166...70:5060) ----> Packet gets blocked by Wingate

[genie]

Right. Can it be a timeout issue - say, the initial packet is being sent from 10.0.0.240 but the replay came after the timeout occurred? What is the time difference between the last packet sent and this firewall message appeared?

[ryhiggin]

I am sending out a new packet every 15 seconds to keep the NAT hole open for the response. (from the inside --> out) It looks like the Wingate only leaves the NAT open for 15-20 seconds.

[genie]

The default timeout for UDP connections is 30 seconds - you can change it using WGOptions utility.

[ryhiggin]

ok - But that shouldn't be affecting me if I see the NAT entry stay open, right?

But the real question is - why isn't it letting the traffic back in? Can I see more detailed logs? I have looked through the NAT log but it doesn't seem to have any information that seems human-readable.

Any assistance on what I can do to get the packet stream to come back in the NAT engine would be appreciated. If this required manipulating the packet headers, I can do this.

Thanks.

[genie]

Hi,
Try reducing your re-request timeout or increate UDP lifespan for Wingate by using WGOptions application. Also, make sure that this .70 machine is not in the blacklist.