1. Home
  2. Cisco Systems
  3. Cisco 877 ACL problem w/ UDP ports

Cisco 877 ACL problem w/ UDP ports

I work for a small software company who is deploying Cisco 800 series routers (877 in particular) to setup VPNs between our customers' stores. Lucky me, I have been assigned the task of configuring these beasts. Anyhow, one of our customers has recently been in the process of having IP phones setup at their premises. Needless to say, since my company installed the router, I have been working with their local telecom in an attempt to add the necessary ACL rules to get the phones to work properly. However, this has been much more difficult than I first anticipated. I thought this would be as simple as adding an allow udp established type rule. But, obviously, I should have know better. There is no state with a UDP stream! Hence, the only way I can get this to work is by writing really ugly rules allowing lots of incoming UDP traffic on multiple ports. Pretty much no outbound traffic is being denied and I have been told the following ports need to be opened up inbound:

Port 69 for TFTP Port 5060 for SIP Ports 10000-20000 for RTP media stream Port 123 for NTP

Hence, I initially created some rules like this:

access-list 101 permit udp any eq tftp any access-list 101 permit udp any eq 5060 any access-list 101 permit udp any range 10000 20000 any access-list 101 permit upd any eq ntp any

I was told that the traffic could be coming in on multiple IP addresses, so I couldn't specify a particular host in any of the ACL's.

So, that is the background of this quagmire I am in. Apparently, the telcom guys are still experiencing problems. They say that they cannot hear the incoming audio stream. I don't see why this would be happening, but I am no expert. Are there any horrible security implications of opening up a slew of udp ports with a rule like: access-list 101 permit udp any gt 1023 any? I obviously do not want to cause any sort of security problems if at all possible. Also, I came across something briefly that was called, I believe, a reflexive (?) ACL. It provided a way of allowing specified inbound traffic after seeing traffic leaving on a particular port. Is something like this possible on the Cisco 877? Well, I hope this all made some sort of sense. Any help or comments would be appreciated. Thanks!

-Vincent

Reply to
Vincent
Loading thread data ...

You have the port # in the wrong spot.

What your first line there says is that any traffic originating on the outside, that is coming in with a source port of 69, to let through.

Its highly unlikely that the originating source port on the remote computer will be from port 69, instead what you want to specify is the destination port be equal to 69.

access-list 101 permit udp any any eq tftp

Here we have any traffic on the outside from any port, coming into any IP with a destination port of 69 to let through.

Hint: insert log lines in your ACL's while troubleshooting, so you can see what rules get matches and which don't.

Reply to
Doug McIntyre

Doug,

Actually for all three protocols (NTP, TFTP and SIP) the source and destination ports are the same. The only thing that isn't the same (I think) are the ports for the RTP media stream. However, I cannot predict the destination port because, for whatever reason, the Cisco firewall logs showed the NAT translated port number (for RTP) was being dropped, not the actual port the service was bound to. I have no idea why it was doing this.

-V> "V> >...I have been told the following ports need

Reply to
Vincent

I am not clear exactly what you are proposing, I will try a couple of assumptions.

- 877 is on the Internet - There is an IPSEC vpn between this router and head office - All phone traffic passes over the VPN. - You want to restrict traffic between the inside of the 877 site and the inside of the Head Office site.

To deal with the phone traffic udp ports being dynamically selected you /may/ be able to use /ip inspect/ on the 877.

In this case it would have to be applied on the inside interface. You would permit

I do not know if ip inspect can handle the protocol that you are using however it offers:-

rtsp Real Time Streaming Protocol sip SIP Protocol sip-tls SIP-TLS skinny Skinny Client Control Protocol

If you were to turn on SIP inspect, the router would look inside the SIP packets and temporarily open the correct ports for the RTP traffic.

To use inspect you apply deny any any Access lists to the interfaces in the appropriate direction, permit the control traffic and let inspect do the rest.

ip inspect name INS.vlan1.in sip ip inspect name INS.vlan1.out sip

int vlan 1 ip access-group ACL.vlan1.in in ip access-group ACL.vlan1.out out

ip inspect INS.vlan1.out out ip inspect INS.vlan1.in in

! I don't know if skinny originates connections ! from both sides or not but the following ! assumes that it does.

ip access-list extended ACL.vlan1.in permit tcp local.lan voice.sources eq skinny deny ip any any ! VITAL this blocks what you don't want

ip access-list extended ACL.vlan1.out permit tcp voice.sources local.lan eq skinny deny ip any any ! VITAL this blocks what you don't want

Clearly you may want to permit more traffic than this so you will usually want more inspect(ion):-

ip inspect name INS.test ftp ip inspect name INS.test h323 ip inspect name INS.test icmp ip inspect name INS.test rcmd ip inspect name INS.test realaudio ip inspect name INS.test rtsp ip inspect name INS.test esmtp ip inspect name INS.test sqlnet ip inspect name INS.test streamworks ip inspect name INS.test tftp ip inspect name INS.test tcp router-traffic ip inspect name INS.test udp router-traffic ip inspect name INS.test vdolive ip inspect name INS.test cuseeme

That's all I am going to write for now. Ask again if you need more.

Reply to
Bod43

Protocols rarely use the same ports for source and destination.

What if you wanted to TFTP 3 files concurrently from one machine to three different servers? If you have the source port bound to port 69, your other two transfers would fail to bind on source port 69.

The lp protocol has some sever limitations in the source port, and ran into major problems such that the RFC was revised to allow for more source ports. No other protocol I know of restricts the source port to a certain value, or if it did 30 years ago, long ago abandonded that as non-workable.

You'll still need to change around your ACL's to account for opening up the destination port.

Reply to
Doug McIntyre

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.