cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
322
Views
0
Helpful
3
Replies

ugh, access list issues again

brandon.vogel
Level 1
Level 1

My simple access lists (IP incoming on the serial port of a 2610 router connected to a T-1 to the Internet) are giving me headaches again. I've got a machine on the network that runs PCAnywhere and a couple of VPN clients. I set the access-list to allow (again, this is incoming to the serial port) the VPN software and suddenly PCAnywhere cannot communicate to hosts. The machine is static NATted if that matters. Unless I put in a permit all for that machine, it cannot work with PCAnywhere for some odd reason.

Here's some of the lines in my access-list statement (public ip's substutited):

access-list 101 permit tcp any any established log

access-list 101 permit udp any eq domain any log

access-list 101 permit tcp any host yy.yy.97.4 eq smtp

access-list 101 permit ip host xx.xx1.25 host yy.yy.97.53 log

The issue is with the .53 machine. The VPN client goes to the xx.xx address, and with that line in and not

access-list 101 permit ip any yy.yy.97.53

PCAnywhere no longer functions for that machine. I thought that the 'permit any tcp established' would cover that. Am I crazy?

Running firewall IOS but do not have inspect statements on.

Any thoughts?

3 Replies 3

kevin-reynolds
Level 1
Level 1

pcanywhere operates on two ports, tcp 5631 and udp 5632. 5631 being the data port and 5632 being the status port.

http://service1.symantec.com/SUPPORT/pca.nsf/docid/1999110411575512

While the tcp established command might take care of the tcp it does not take care of the udp port. If the foreign client never has to initiate any tcp connections to your internal host then it is good. But your ACL shut off the udp portion.

access-list 101 permit udp any yy.yy.97.53 eq 5632

This should take care of it. If it still does not work then you may just have to permit tcp 5631 to your .53 machine.

As for the VPN, just permit the specific ports and protocols point to point in our ACL. If you are using IPSEC then the following MAY do it (depending on your set up)

access-list 101 permit udp host x.x.x.25 host y.y.y.53 eq 500

access-list 101 permit esp host x.x.x.25 host y.y.y.53

Hope this helps.

Kevin

Tried the esp and IPSEC lines and still cannot get connectivity to our customer with the Nortel software VPN client. No clue why, because it SHOULD work. I thought it could be NATting that messes it up, but when I open the firewall entirely to that IP, it works fine.

The machines inside my network are the ones that are originating the PCAnywhere connections, so I don't understand why I'd have to open up the fireawll to allow that UDP traffic in for the statusport. Am I incorrect about that?

I would say that you are incorrect about that. Just because it is connectionless does not mean it is one way. Look at DNS, it is connectionless yet consists of a request and a reply both using UDP port 53.

As far as your VPN, it could be using any number of protocols (AH, ESP, GRE...) you just need to find what you are using and allow them bi-directioanlly.

You could put "deny ip any any log" at the end of your ACL and look at the traffic being blocked.

Kevin