Zone-Based Firewall: "pass" action doesn't work with UDP...only "inspect"

[kbogart368]

Hi everyone,

I've been experimenting with ZBFW using three routers, all running 15.3(3)XB12 and have run across an interesting problem.

R3(Client= 3.3.3.3) -----Fa0/1.33 [R1(ZBFW)]-Serial1/3 ----- R4(Internet-Rtr = 4.4.4.4)

When class-maps are configured (matching any UDP protocols such as TFTP or DNS) and the associated Policy-Map uses the "pass" action, traffic is passed from source-to-destination...but the reply traffic is dropped (even though a matching zone-pair is applied in the reverse direction also specifying "pass" in the Policy-Map).  If the Policy-Map is applied with an "inspect" action...traffic passes bidirectionally.

The "pass" action within the policy-map (used by ZBFW) works just fine with TCP and ICMP traffic...just not UDP-based traffic.

Any ideas?

ZBFW configuration with "pass" actions that drops reply-traffic:

ZBFW#sh run

Building configuration...

!

version 15.3

!

hostname ZBFW

!

ip cef

!

class-map type inspect match-all ICMP

match access-group 102

class-map type inspect match-all Pass-TFTP

match protocol tftp

class-map type inspect match-all DNS

match protocol dns

!

policy-map type inspect In-to-Out

class type inspect ICMP

  inspect

class type inspect Pass-TFTP

  pass

class type inspect DNS

  pass

class class-default

  drop

!

policy-map type inspect Out-to-In

class type inspect Pass-TFTP

  pass

class type inspect DNS

  pass

class class-default

  drop

!

zone security Payroll ##(this is the zone connected to R3)

zone security Internet ##(this is the zone connected to R4)

!

zone-pair security Payroll-to-Internet source Payroll destination Internet

service-policy type inspect In-to-Out

!

zone-pair security Internet-to-Payroll source Internet destination Payroll

service-policy type inspect Out-to-In

!

interface FastEthernet0/1.33

Description To-R3-Client-Router

encapsulation dot1Q 33

ip address 3.3.3.1 255.255.255.0

zone-member security Payroll

!

interface Serial1/3

Description To-R4-Internet-Router

ip address 4.4.4.1 255.255.255.0

zone-member security Internet

clock rate 128000

!

ip route 44.0.0.0 255.0.0.0 4.4.4.4

!

access-list 102 permit icmp any any

!

end

***************************

UDP Traffic initiated on R3-Client (TFTP-based):

R3-CLient#copy tftp flash:
Address or name of remote host [4.4.4.4]?
Source filename [startup-config]? Test-Config
Destination filename [Test-Config]?
Accessing tftp://4.4.4.4/Test-Config...
%Error opening tftp://4.4.4.4/Test-Config (Timed out)
R3-CLient#

Below is proof that this UDP-based TFTP traffic is reaching the R4-Internet router, and being responded to...but being dropped at the Zone-Based Firewall on the return path:

R4-Internet#show log

Log Buffer (4096 bytes):

.Jan 22 13:21:49.903: UDP: rcvd src=3.3.3.3(55338), dst=4.4.4.4(69), length=28
.Jan 22 13:21:49.903: Reserved port 52077 in Transport Port Agent for UDP IP type 1
.Jan 22 13:21:49.907: TFTP: Server request for port 55338, socket_id 0x4D85DFB8 for process 276
.Jan 22 13:21:49.907: TFTP: read request from host 3.3.3.3(55338) via Serial1/3
.Jan 22 13:21:49.907: TFTP: Looking for Test-Config
.Jan 22 13:21:49.907: TFTP: Opened flash:Test-Config, fd 0, size 1688 for process 276
.Jan 22 13:21:49.911: TFTP: Sending block 1 (retry 0), len 512, socket_id 0x4D85DFB8
.Jan 22 13:21:49.911: UDP: sent src=4.4.4.4(52077), dst=3.3.3.3(55338), length=524
.Jan 22 13:21:53.903: UDP: rcvd src=3.3.3.3(55338), dst=4.4.4.4(69), length=28
.Jan 22 13:21:53.903: Reserved port 63626 in Transport Port Agent for UDP IP type 1
.Jan 22 13:21:53.903: TFTP: Server request for port 55338, socket_id 0x4D9D70A8 for process 300
.Jan 22 13:21:53.907: TFTP: read request from host 3.3.3.3(55338) via Serial1/3
.Jan 22 13:21:53.907: TFTP: Looking for Test-Config
.Jan 22 13:21:53.907: TFTP: Opened flash:Test-Config, fd 1, size 1688 for process 300
.Jan 22 13:21:53.907: TFTP: Sending block 1 (retry 0), len 512, socket_id 0x4D9D70A8

*****************************************

The same thing happens with DNS traffic:

R3-CLient#ping R4Loop
Translating "R4Loop"...domain server (4.4.4.4)
% Unrecognized host or address, or protocol not running.

R4-Internet#debug domain
Domain Name System debugging is on
R4-Internet#

.Jan 22 13:26:37.843: DNS: Incoming UDP query (id#36141)
.Jan 22 13:26:37.843: DNS: Type 1 DNS query (id#36141) for host 'R4Loop' from 3.3.3.3(53811)
.Jan 22 13:26:37.843: DNS: Servicing request using view default
.Jan 22 13:26:37.843: search_nametype_index: R4Loop
.Jan 22 13:26:37.843: search_nametype_index: found R4Loop for R4Loop
.Jan 22 13:26:37.843: DNS: Reply to client 3.3.3.3/53811 query A
.Jan 22 13:26:37.843: DNS: Finished processing query (id#36141) in 0.000 secs
.Jan 22 13:26:37.843: DNS: Sending response to 3.3.3.3/53811, len 40

****************************************

Now I change both Policy-Maps to use the "inspect" action. After doing so, my UDP traffic (both TFTP and DNS) are successful:

*****************************************

ZBFW(config)#
ZBFW(config)#policy-map type inspect In-to-Out
ZBFW(config-pmap)#class type inspect Pass-TFTP
ZBFW(config-pmap-c)#no pass
ZBFW(config-pmap-c)#inspect
ZBFW(config-pmap-c)#exit
ZBFW(config-pmap)#class type inspect DNS
ZBFW(config-pmap-c)#no pass
ZBFW(config-pmap-c)#inspect
ZBFW(config-pmap-c)#exit
ZBFW(config-pmap)#exit
ZBFW(config)#policy-map type inspect Out-to-In
ZBFW(config-pmap)#class type inspect Pass-TFTP
ZBFW(config-pmap-c)#no pass
ZBFW(config-pmap-c)#inspect
ZBFW(config-pmap-c)#exit
ZBFW(config-pmap)#class type inspect DNS
ZBFW(config-pmap-c)#no pass
ZBFW(config-pmap-c)#inspect
ZBFW(config-pmap-c)#end
ZBFW#

**************************

R3-CLient#copy tftp flash:
Address or name of remote host [4.4.4.4]?
Source filename [Test-Config]?
Destination filename [Test-Config]?
Accessing tftp://4.4.4.4/Test-Config...
Loading Test-Config from 4.4.4.4 (via FastEthernet0/0): !
[OK - 1688 bytes]

1688 bytes copied in 0.752 secs (2245 bytes/sec)

R3-CLient#

R3-CLient#ping R4Loop
Translating "R4Loop"...domain server (4.4.4.4) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 44.44.44.4, timeout is 2 seconds:
!!!!!

[Mohammed al Baqari]

Hi,

To my understanding, pass action has to be applied in both directions
because it treats the router as stateless firewall. I don't think TCP or
ICMP will be allowed if you don't have a zone-pair configure on the reverse
direction with pass action.

[kbogart368]

Thank you for the reply Mohammed, however I do have zone-pairs in both directions...both of which are referencing Policy-Maps containing the "pass" action for TFTP and DNS traffic, so that doesn't appear to be the reason this traffic is being dropped on the return path:

Here's a snippet of the config I posted in my original message:

zone-pair security Payroll-to-Internet source Payroll destination Internet

service-policy type inspect In-to-Out

!

zone-pair security Internet-to-Payroll source Internet destination Payroll

service-policy type inspect Out-to-In

[Mohammed al Baqari]

But for tftp you can't use pass and match port 69 only because tftp use
dynamic high port for data transfer. You need inspect action for tftp

[kbogart368 · Accepted solution]

Hello Mohammed,

I am not matching TFTP by referencing an ACL.  I'm using the "match protocol tftp" statement within my Class-Map. 

However, you're right...I didn't think about the dynamic nature of TFTP ports. And (for protocols that don't randomize their ports like DNS) I was assuming that "match protocol" would match well-known port-numbers regardless of whether they were seen in the Source or Destination TCP/UDP Port fields...but is clearly not the case.

So the answers to this problem are:

--When using the "match protocol" option within a Class-Map (referenced by a ZBFW Policy-Map), all that is being matched against are well-known destination port numbers (not source ports). Therefore:

----A. If the "inspect" action is used within the Policy-Map, the "match protocol" will match on the well-known destination port number of the protocol, and allow the outbound traffic to pass between zones. As this occurs, the outgoing traffic will create a stateful entry in which both the source (Ephemeral port) and destination (well-known port) port numbers will be cached.  Therefore the swapping of source/destination port numbers (when return traffic is received) can be recognized and allowed to be received.

----B.If the "pass" action is used within the Policy-Map, no stateful entry is created in the router.  Therefore, the "match protocol" will match on the well-known destination port number of the protocol, and allow the outbound traffic to transparently pass between zones. However...

----------i. If reply traffic is received in which the well-known port-number is now in the TCP/UDP Source Port field...the "match protocol" field will not match. Traffic will not be matched and will be dropped.  In this case, an Access-List should be utilized to match return traffic in which the well-known port number is now in the TCP/UDP Source Port field.

----------ii. If reply traffic is received that has swapped the well-known port number for an Ephemeral Port (such as is utilized with TFTP data transfers) then the "match protocol" field will not match and traffic will be dropped. Creating a matching Access-List will be pointless (unless one is willing to permit the entire range of Ephemeral Ports to pass).

Thanks for helping me to understand this!

Keith

[Mohammed al Baqari]

Great that you got this sorted. FYI, match protocol tftp and matching an
ACL on port 69 are same as you got to know now.

**** Remember to rate useful posts