Solved

Watchguard Firebox x10e Edge dropping outgoing udp

Posted on 2012-03-09
15
1,478 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
  • 9
  • 6
15 Comments
 
LVL 32

Expert Comment

by:dpk_wal
Comment Utility
>> 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
Comment Utility
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
Comment Utility
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
 
LVL 32

Expert Comment

by:dpk_wal
Comment Utility
Can you send sanitized screen-shots of your configuration.

Thank you.
0
 

Author Comment

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

Expert Comment

by:dpk_wal
Comment Utility
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
Comment Utility
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
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 

Author Comment

by:mgchar7
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
Sure; please update your findings.
0
 

Author Comment

by:mgchar7
Comment Utility
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
Comment Utility
Patience is key sometimes!  dpk_wal is top notch, thanks!
0
 

Author Comment

by:mgchar7
Comment Utility
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
Comment Utility
Thank you for the update and points; happy that the problem is resolved! :)
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

In this tutorial I will show you with short command examples how to obtain a packet footprint of all traffic flowing thru your Juniper device running ScreenOS. I do not know the exact firmware requirement, but I think the fprofile command is availab…
Optimal Xbox 360 connectivity requires "OPEN NAT". If you use Juniper Netscreen or SSG firewall products in a home setting, the following steps will allow you get rid of the dreaded warning screen below and achieve the best online gaming environment…
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

743 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

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now