Home / server / Questions / 218965
Accepted
700 Software
Asked: 2011-01-06 05:40:24 +0800 CST

Cisco IOS BVI ACL: Only allow established UDP

  • 772

Related: Cisco IOS ACL: Don't permit incoming connections just because they are from port 80

I know we can use the established keyword for TCP.. but what can we do for UDP (short of replacing a Bridge or BVI with a NAT)?

Answer

I found out what "UDP has no connection" means.

DNS uses UDP for example..

  1. named (DNS server) is lisenting on port 53
  2. nslookup (DNS client) starts listening on some random port and sends a packet to port 53 of the server and notes the source port in that packet.
  3. nslookup will retry 3 times if necessary. Also the packets are so small that it does not have to worry about them coming in the wrong order.
  4. If nslookup receives a response on that port that comes from the servers IP and port then it stops listening. If the server tried to send two responses (for example a response and a response to the retry) then the server would not care if either of them made it because the client has the job to retry. In fact.. unless ICMP 3/3 packet gets through the server would not know about a failure. This is different from TCP where you get connection closed or timed out errors.

DNS allows for an easy retry from the client as well as small packets.. so UDP is an excellent choice because it is more efficient. In UDP you would see

  1. nslookup sends request
  2. named sends answer

In TCP you would see

  1. nslookup's machine sends SYN
  2. named's machine sends SYN-ACK
  3. nslookup's machine sends ACK and the request
  4. named's machine sends the response

That is much more than is necessary for a tiny DNS packet

cisco access-control-list ios bridge-router

2 Answers

  1. Best Answer

    UDP packets don't establish a connection, they're literally fire and forget! A simple permit udp host XX.xx.xx.xx host xx.xx.xx.xx eq xx should be all that's required.

    • 1

  2. Accidentally stumbled upon this page while searching for something else, and thought to add a couple of cents...

    Short of doing stateful firewall on IOS, you can use a long existing feature called "reflexive ACL" - where a packet in one direction pokes a hole in the ACL, and this permits the packets in the the other direction.

    Configuration guide describes the feature in full detail, but in a nutshell, it is as follows:

    • you can have an entry within an access list that, besides permitting the packets, also can reflect this traffic in a reflexive ACL (which is a fully dynamic entity)
    • in another ACL you can evaluate this reflexive ACL as part of the ACL matching process alongside the usual permit and deny.

    here's a simple example of a config:

    interface Dialer1
  ip address negotiated
  ip access-group V4-GATE in
  ip access-group V4-REF out
!
ip access-list extended V4-GATE
  permit icmp any any echo-reply
  permit icmp any any unreachable
  permit icmp any any ttl-exceeded
  permit icmp any any packet-too-big
  evaluate V4-REFLECTOR
  deny   ip any any log
!
ip access-list extended V4-REF
  permit udp any any eq domain reflect V4-REFLECTOR timeout 10
  permit ip any any reflect V4-REFLECTOR
!

    This will give you pretty much exactly the same amount of statefulness as the NAT overload.

    HTH.

    (EDIT: seeing you mention BVI - maybe the applicability of this will depend on your configuration. What I illustrated above is where the Dialer1 is the egress interface connecting to the internet. If you do router-on-a-stick, you might need to adapt this - though I think it is still applicable. This is unusable if the interfaces connecting the two pairs of the connection are members of the same bridge group)

    • 1