Solved

Watchguard Firebox x10e Edge dropping outgoing udp

Posted on 2012-03-09
15
1,537 Views
Last Modified: 2012-03-14
Been beating my head against the wall trying to figure out why this Firebox is dropping outgoing UDP (to ports 6000, 9000-9001, 30000-30031).  I setup a Custom Packet Filter Policy to allow traffic in/out for a Samsung IP phone that is running outside the network.  The phone connects from an outside network to the inside network call center but there is no sound on the phone-it can make calls, but the user cant hear anything.  The Firebox is dropping outgoing udp even with the Custom Packet Filter Policy explicitly permitting All Outgoing From ANY to ANY.  The syslog shows the following:
--------------------
Mar 9 18:12:23  kernel  deny out eth1 60 udp 20 64 192.168.1.115 192.168.1.1 1024 6000 (default)
--------------------
I get the same denys for port 30000-30031 as well.  
Essentially, I need the Firebox to ALLOW UDP/TCP traffic OUT on (TCP6000, UDP6000, UDP9000-9001 and UDP30000-30031).  
This Firebox is running software version 10.0  (I miss Cisco!)
Help!
0
Comment
Question by:mgchar7
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 9
  • 6
15 Comments
 
LVL 32

Expert Comment

by:dpk_wal
ID: 37706026
>> Mar 9 18:12:23  kernel  deny out eth1 60 udp 20 64 192.168.1.115 192.168.1.1 1024 6000 (default)

Above log indicates that you are trying to send a packet OUT of firebox, source IP 192.168.1.115 and destination IP 192.168.1.1. Why is your machine sending traffic to 1.1 [which I think is your firebox IP]; shouldn't your machine .115 send traffic to actual host/server on the internet on its public IP.

By default Outgoing or Outgoing-proxy Policies would allow all OUT traffic from ANY host on the internal network to ANY external host.

Reading you post my initial thought was that you need policy for incoming traffic; but then the log and your further post indicate you wish to have outbound traffic allowed; which should natively be allowed; so am not sure what you wish to configure here.
If you have disabled Outgoing to Outgoing-proxy policy; enable it again and then all Outbound traffic would be allowed.

To allow inbound traffic; please make sure that the policy you have created is correct; have a look at articles below:
http://www.watchguard.com/help/docs/fireware/10/en-US/Content/en-US/policies/custom_policies_about_c.html

http://www.watchguard.com/education/video/play.asp?vid=ff_edge_ingress

Please provide more details.

Thank you.
0
 

Author Comment

by:mgchar7
ID: 37707736
Thank you.
To further elaborate.  
-There is an Out Policy allowing Any-Any.  
-192.168.1.115 is a Samsung call center IP phone system.  
-The default gateway for the network is the Watchguard inside eth1 (192.168.1.1)
-No other inside services are having trouble connecting to outside clients


Here is another summary of what I need to do and have done:
To get the outside phone connecting to the inside call center, I setup a new incoming Packet Filter Policy to allow UDP/TCP traffic In (TCP6000, UDP6000, UDP9000-9001 and UDP30000-30031), then on the Outgoing tab, I chose Any-Any and set the Rule to Allow.
So I have a new explicit packet filter policy allowing traffic in/out on the ports I need.  

So now, I look at the Proxy Policy.  The default Proxy Policy should already just work.  There was already an Outgoing Proxy Policy allowing Host-Any to Host-Any as well as TCP/UDP/Protocol-Any outgoing.  This was a default Policy from the factory config that essentially allows all traffic all ports all protocols outgoing to be allowed-mostly all routers/firewalls have this setting as their default config-as you already established.
 
So I am stumped as to why the syslogs are reporting blocked UDP traffic destined to the outside via the inside NAT'd (ETH1) address of the Firebox 192.168.1.1???  By design ALL inside traffic destined for an outside host MUST be NAT'd via 192.168.1.1-then translated by the router to the outside destination address-correct?  

There is no explicy policy/rule denying outgoing UDP.  I know why the outsde phone has no audio-outgoing udp packets containing audio are being dropped by the Watchguard-per the syslog.  I just need to know why?  Any further insight would be very much appreciated!
0
 

Author Comment

by:mgchar7
ID: 37707743
To futher elaborate, the .115 has a default gateway set which is, 1.1, this is why it is sending udp packets to that adddress.  The packet filter policy I have set should explicitly permit the .115 policy host to send anything out of the network-along with the default proxy out policy.
0
Now Available: Firebox Cloud for AWS and FireboxV

Firebox Cloud brings the protection of WatchGuard’s leading Firebox UTM appliances to public cloud environments. It enables organizations to extend their security perimeter to protect business-critical assets in Amazon Web Services (AWS).

 
LVL 32

Expert Comment

by:dpk_wal
ID: 37709238
Can you send sanitized screen-shots of your configuration.

Thank you.
0
 

Author Comment

by:mgchar7
ID: 37709528
Yes, here are the Firewall, Outgoing Packet Filter Policy and Incoming settings.
watchguard-screenshots.doc
0
 
LVL 32

Expert Comment

by:dpk_wal
ID: 37710133
I still do not understand why is the destination IP address on the packet 192.168.1.1 when your phone system sends out packet; the destination IP should be a public IP on the internet.
FB would do NAT for source IP; but not for destination IP when the traffic is outbound.

Do not understand what common policy does. May be you can disable it.

Policy named samsung-inout is correctly configured.

Am I missing on some detail?

Please advice.
0
 

Author Comment

by:mgchar7
ID: 37710202
To explain, the outside phone connects to the inside call center, so the initiating connection is from the outside.  The inside call center connects and allows the phone to make calls but there is no sound on the phone.  So what is happening is during the TCP/UDP session the call center is trying to reply to the phone with udp voice packets over port 6000, but the FB is dropping the connections.
The reason the inside call center is sending packets to 1.1 is that is the default gateway on the call center-and the inside eth1 on the FB.  The inside call center is trying to send to the outside IP but it is being dropped by the FB.
Do you think it would make sense to set the outgoing host on the samsung-inout policy to the IP that the outside phone is behind?
0
 

Author Comment

by:mgchar7
ID: 37710575
I agree about outbound traffic not needing to be nat'd, but I have no other explanation (based on the logs) for why 1.1 is dropping outgoing udp other than it cannot understand how to translate it (for this particular device .115)
0
 
LVL 32

Accepted Solution

by:
dpk_wal earned 500 total points
ID: 37712982
Let me try to explain what my understanding of the problem is.

Assumptions:
===========
1. Public IP of client outside which is initiating call to call manager is 1.1.1.1.
2. Public IP of WG internet facing or outside interface is 2.2.2.2.

Facts:
=====
1. Internal IP of call server, behind WG trust interface is 192.168.1.115.
2. Internal IP of WG trust interface is 192.168.1.1.

Scenario I:
=========
The phone on the outside or internet initiates a connection to call manager behind WG.
So, the IP/TCP values in header would look something like this:
Source IP: 1.1.1.1; destination-IP: 2.2.2.2; TCP/6000; SYN

When this packet hits the external interface of WG; WG does destination IP translation and the packet becomes:
Source IP: 1.1.1.1; destination-IP: 192.168.1.115; TCP/6000; SYN

Now the packet reaches your phone system and it would reply back to 1.1.1.1 and the packet would look like:
Source IP: 192.168.1.115; destination-IP: 1.1.1.1; TCP/6000; SYN/ACK

WG would now do source NAT on this packet and the packet goes to internet as:
Source IP: 2.2.2.2; destination-IP: 1.1.1.1; TCP/6000; SYN/ACK

Scenario II:
=========
Call manager behind WG initiates a connection to outside host:

The IP/TCP values in header would look something like this [IMP: note the destination IP is 1.1.1.1 and NOT 192.168.1.1]:
Source IP: 192.168.1.115; destination-IP: 1.1.1.1; TCP/6000; SYN

When this packet hits the internal interface of WG; WG does source IP translation and the packet becomes:
Source IP: 2.2.2.2; destination-IP: 1.1.1.1; TCP/6000; SYN

Now the packet reaches the host on the internet and it would reply back to 2.2.2.2 and the packet would look like:
Source IP: 1.1.1.1; destination-IP: 2.2.2.2; TCP/6000; SYN/ACK

WG would now do destination NAT on this packet and the packet goes to internal call server as:
Source IP: 1.1.1.1; destination-IP: 192.168.1.115; TCP/6000; SYN/ACK

=======
In all the above scenarios; the call manager would not send traffic to WG with detination IP 192.168.1.1; because then the traffic is destined for WG itself.
WG should be listening for incoming packets on TCP/6000 for accepting the packet from call server; which it is not and hence drops the packet.

Please let know if you need more details.

Thank you.
0
 

Author Comment

by:mgchar7
ID: 37714066
Thank you for breaking that down.  
I do understand that .115 should be sending to the outside host not 1.1.  None of the logs indicate traffic is destined from .115 to an outside host however-thats why I felt there was a config issue on the WG.  I will take this to Samsung for further review as to why Samsung inside call center is behaving in this manner.  Thank you again.  I will let you know as soon as I hear something.
0
 
LVL 32

Expert Comment

by:dpk_wal
ID: 37718329
Sure; please update your findings.
0
 

Author Comment

by:mgchar7
ID: 37720655
Ok, your last comment and breakdown of the tcp-syn-ack illustration essentially got this resolved.  I'm just a tech consult for the company having this issue-they outsourced their phone system to another consultant.  I sent that most recent post on this issue to their VOIP Consultant and to a Samsung engineer.  He suggested we replace the interface on the inside Samsung device.  It is working now!  Their response,  "since the inside call center intf0 is responding to NAT'd incoming packets with destination address of inside dflt gtw (192.168.1.1) instead of outside ip in ack is evidence of interface failure or misconfiguration (either on the router or interface config on the call center)."  Since we I already verified the WG is configured, I called the VOIP Consultant and emailed Samsung-they reset and reconfigured the interface and it now works.  Syslogs are showing outgoing traffic destined for outside IP host translated with Samsung-inout packet filter policy.  
Thanks for you time and help with this!!!   It took a lot of evidence to show there was a Samsung issue, not WG config issue.     I know this was a pain, but thanks again for your effort!
0
 

Author Closing Comment

by:mgchar7
ID: 37720664
Patience is key sometimes!  dpk_wal is top notch, thanks!
0
 

Author Comment

by:mgchar7
ID: 37720676
I should also clarify-the interface on the Samsung inside device was reconfigured with outside IP and routing, not replaced-sorry for any confusion.
0
 
LVL 32

Expert Comment

by:dpk_wal
ID: 37723366
Thank you for the update and points; happy that the problem is resolved! :)
0

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Network traffic routing plays key role in your network, if you have single site with heavy browsing or multiple sites, replicating important application data from your Primary Default Gateway ,you have to route your other network traffic from your p…
This article offers some helpful and general tips for safe browsing and online shopping. It offers simple and manageable procedures that help to ensure the safety of one's personal information and the security of any devices.
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
Finds all prime numbers in a range requested and places them in a public primes() array. I've demostrated a template size of 30 (2 * 3 * 5) but larger templates can be built such 210  (2 * 3 * 5 * 7) or 2310  (2 * 3 * 5 * 7 * 11). The larger templa…

726 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question