tcp vs. udp in ACL

Kevin Melton · ‎09-02-2008

I have the following statement in an ACL on a customer's border router:

10 permit tcp any any established (48131145 matches)

I was curious if there was any opportunity to write a similar rule for udp, or whether writing a rule that uses "established" for UDP was even valid..

I am not sure about this in light of the fact that TCP is connection oriented, this is what I thought when the ACL statement uses the verbage "established". It was my idea that this may not be able to be written for UDP since it is connectionless, and therefore probably does not establish anything with respect to sessions.

Any input would be welcome.

scottmac · ‎09-02-2008

"Established" wouldn't work for UDP ... there are no sessions (at that level).

Any "session" establishment, like any error-control or recovery for traffic implementing UDP must be done at higher levels, usually application (like for TFTP).

So, to monitor a "session" that uses UDP, the firewall must do deeper packet inspection, and if it is an option to do something (ot not) based on that "session", then the firewall code must be written specifically to do it.

I believe that is one of the functions for some of the "fixup" commands / statements in PIX-IOS.

It would belong to the engine that tracks the stateful inspection functions.

As you mention at the bottom of your post, there is no layer four connection (ala TCP), so there would be no mechanism to track it (though, depending on the application, you may find TCP-like functionality intrduced at a higher level, like TFTP).

Good Luck

Scott

Jon Marshall · ‎09-02-2008

Just to add to Scott's post. Even stateful firewalls have a rather basic approach to UDP (if there is no fixup for it). Because a stateful firewall by definition relies on state eg TCP SYN/SYN ACK/ACK etc. UDP can present problems.

Generally what a stateful firewall does it simply set a timer when it sees an outbound UDP packet, records the IP addresses and port numbers and then it only allows packets back in that have the corresponding IP address/port numbers before the timer expires.

You can usually modify the timeout for UDP connections on a firewall.

Jon

gnijs · ‎05-08-2018

Indeed, but i wonder if the same can be possible on an ASR1001X router for example: keeping this timer for return packets. why ? well, because of Cisco :-) and in particular Cisco WebEx. WebEx by default tries to connect to UDP/9000, but how do i need to match the return traffic if i need to pass the traffic through an ACL on an Internet Border router (before the firewall) ??

Of course, i can open ALL UDP/9000 source traffic, or i can try to limit this to Cisco WebEx server sources only, but it would be great if i did not have to do this manually, but that the router would allow automatic UDP return traffic to the same source port, if the reply comes within 20 seconds or so.

Joseph W. Doherty · ‎09-02-2008

The idea behind using permit tcp any any established is usually to provide a quick and dirty method to allow TCP packets in from the "outside" that appear to be in reply to a TCP session started from the inside. No real session flow state information needs to be retained.

(Since there's no real state information, it's possible to forge a TCP packet on the outside that would pass this ACL, but because of the other TCP session rules, there's little security risk although it could be used for a DoS attack against bandwidth. Real TCP state would likely drop such a forged packet.)

As you note, since UDP doesn't have sessions, at the protocol level, there isn't any way to easily determine UDP packets are a reponse to something inside without keeping state information.

On routers without the firewall feature set, where you often find the "tcp established" ACL, you might be able to use a reflexive ACL for UDP, or other protocol, including TCP, "sessions".

For more information on this type of ACL, see: http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfreflx.html

Kevin Melton · ‎09-03-2008

the reason I was asking about this is as follows:

I have a 3825 ISR on my customers Internet border. I have an ACL configured that is installed on the Internet side Interface in an inbound direction.

The customer is a Resort Hotel. They provide a subscriber gateway that is installed behind the border router. The subscriber gateway handles all of the NAT for the VPN's where necessary. The problem is that we have a handful of Guest Users whom arrive at the Hotel, try to use their VPN clients, and then fail. One of the bandaids that will allow these failing users, however, is to lift the ACL off of the border router. For some reason that will allow the VPN clients to then connect. This is all very awkward to me, as I would have thought that since the VPN connection originated INSIDE our network, and was returning, that the Router would allow it back in. I may be missing something in my thinking with this.

I appreciate all of your thoughts on this.

I would really like to fix the problem without having to remove the ACL each time a Guest User has trouble.

Kevin

STEVE DUE · ‎09-03-2008

if your vpn sessions are using ipsec they use upd for ike, try adding an acl to allow udp into the guest devices only, setup a scope for guest to recieve a certain ip range and allow udp to that see what happens.

Joseph W. Doherty · ‎09-03-2008

Well it could be as simple as some VPNs, although started from the inside, are making a new session from the outside. Similar to the differences between active and passive FTP.

A simple way to deal with this, would be if the router allowed "new" external inbound TCP traffic as long as the SA matched a former DA (within a small time period). I don't have enough experience in this area to suggest Cisco products with feature. You might want to post in the security forum.

Otherwise, you could try allowing in "new" outside TCP especially if you could identify the ports being used by these VPNs. (The "new" but without port restriction is likely what happens when you remove the established ACL.) Or, block other common TCP server ports, e.g. port 80.

[edit]

PS:

Steve mention of UDP, brings to mind I may have mis-read whay you intended to say in your response. Do you remove the whole ACL or just the line with the TCP established?

If it's just the one ACL line, it could be as I described. If the whole ACL, it could be you just need to modify your ACL. Since your initial question also was about UDP, a reflexive ACL for UDP might solve your problem, or even openning up some special ports that would, in themselves, make for little extra security risk.

STEVE DUE · ‎09-03-2008

if the guest on the inside are trying to connect to there home vpn device and are using ipsec, The IKE key-negotiation protocol uses UDP port 500, therfore i would suspect the key negotiation would fail. You can also look at the logs on your device and the logs on the vpn client to see if this is what is happening.