cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
419
Views
0
Helpful
7
Replies

Routing Issue or ACL issue with Pix 510

Robeasts99
Level 1
Level 1

I have a server (A) behind a Pix 510 that is requesting udp traffic on port 7004 from a server (B) outside of the PIX. I can ping Server B from Server A. In one of my wireshark captures I see that server A is requesting UDP traffic on port 7004, but it doesn't look to be getting through the PIX. I cannot ping server B from the PIX for some reason, but server B can ping the outside interface of the PIX. Below are my ACLs

access-list outside_access_in permit udp host Server_B interface outside eq 7004

access-list outside_access_in permit icmp any any

I would like to think my ACLs are right is there a problem with the routing? I wouldn't think so because I can ping between the servers. Any help is appreciated. Thanks.

7 Replies 7

Jon Marshall
Hall of Fame
Hall of Fame

If the traffic is initiated from inside ie. Server A then you shouldn't need a line in out outside_access_in acl because the pix is stateful so it will allow the traffic back in automatically.

Could you post

1) the pix config

2) the IP address of Server A and server B

Jon

bmcginn
Level 3
Level 3

Hi there,

in addition to removing the permit icmp any any (which you don't need as the pix is a stateful device - as already mentioned above - unless you want outside devices to ping inside devices of course), you might try an additional line in the acl.

access-list outside_access_in permit udp host Server_B eq 7004 interface outside

You mentioned that Server A initiates the connection to Server B. Being UDP, I don't think there is a state being held for the connection; so this ACL allows the return traffic. If server A is the only one initiating traffic, then you can remove the line access-list outside_access_in permit udp host Server_B interface outside eq 7004.

If you want Server B to initiate the traffic however, leave that line in.

You might want to post your config up if you want help diagnosing the "can't ping from pix" problem.

Thanks for the replies. Here is what I got.

name 172.17.1.45 Server_A

name 10.2.1.13 Server_B

access-list outside_access_in permit udp host Server_B interface outside eq 7004

access-list outside_access_in permit icmp any any

ip address outside 10.2.1.98 255.255.0.0

ip address inside 172.17.1.60 255.255.255.192

ip audit info action alarm

ip audit attack action alarm

pdm location Server_B 255.255.255.255 inside

pdm location Server_A 255.255.255.255 outside

pdm logging informational 100

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) interface Server_A netmask 255.255.255.255 0 0

access-group outside_access_in in interface outside

access-group inside_access_in in interface inside

route outside 0.0.0.0 0.0.0.0 10.1.1.1 1

timeout xlate 0:05:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout sip-disconnect 0:02:00 sip-invite 0:03:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server TACACS+ max-failed-attempts 3

aaa-server TACACS+ deadtime 10

aaa-server RADIUS protocol radius

aaa-server RADIUS max-failed-attempts 3

aaa-server RADIUS deadtime 10

aaa-server LOCAL protocol local

ntp authentication-key 3 md5 ********

ntp authenticate

ntp trusted-key 3

ntp server 172.17.1.40 key 3 source inside prefer

http server enable

http 172.17.1.0 255.255.255.192 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

telnet Server_A 255.255.255.255 inside

telnet timeout 5

ssh timeout 5

console timeout 15

terminal width 80

I tried putting in "access-list outside_access_in permit udp host Server_B eq 7004 interface outside" but it wouldn't take it. Would you please explain how that is different than the ACL I already have? Thanks for the help!

Hi again,

access-list outside_access_in permit udp host Server_B eq 7004 interface outside is directing the pix to allow traffic that has a source port of 7004. It differs from access-list outside_access_in permit udp host Server_B interface outside eq 7004 as this is stipulating the destination port.

If Server_B is initiating a connection to Server_A (or A's natted address, the interface adress), it will send a datagram to the pix using destination port 7004 (which is what the original ACL will allow in).

If Server_A is initiating a connection to Server_B, it will send a datagram to Server_B with a destination of port 7004. When Server_B responds to the datagram with one of it's own, it will send with the source port of 7004, not destination port of 7004.

This is a UDP connection and the pix doesn't hold state for it. Therefore you need to have an access list that accepts datagrams from outside with a 'source' port of 7004, rather than a destination port.

Of course, you could put both lines in, which means the pix will accept a connection initiated from Server_B AND the return traffic from a connection initiated by Server_A.

As a troubleshooting step, you could put a deny any any on the end of the ACL and log it to see if it's dropping the packets.

access-list access-list outside_access_in deny ip any any log

I notice you also have an access-group on the inside interface, and no associated access-list. Is this an oversight or is the access-list deliberately omitted from the config you posted?

As for the pix not taking the access-list line, can you ensure it is what I wrote in? The pixes I have here accept it fine :-)

EDIT: Also check to ensure the default gateway for Server_B is pointing to the pix..

Brad

"This is a UDP connection and the pix doesn't hold state for it. Therefore you need to have an access list that accepts datagrams from outside with a 'source' port of 7004,"

Brad, i agree the pix doesn't hold state in the strict sense of the word ie. TCP flags SYN/ACK etc. are not there. But you don't have to explicitly allow UDP both ways because the pix maintains a "pseudo state" for UDP connections. The pseudo state is basically a timer that is started when the initial packet goes through the firewall. So with UDP you should not have to allow traffic back in as the pix should cope with this.

Jon

Jon,

I have always been under the impression that the pix doesn't hold state.

I really like these forums, they help clear up gaps in my knowledge all the time!

Thanks Jon.

Thanks for the help. Server_A is initiating the udp connection to Server_B. So Server_B is sending it back to destination port 7004. I tried putting "access-list outside_access_in permit udp host Server_B interface outside eq 7004" in but it wouldn't take it. Here is what I had for access group for the inside interface "access-list inside_access_in permit ip host Server_A any". Sorry I forgot to put that in. There is a route on Server_A to get to Server_B. Thanks again for the help.

Review Cisco Networking products for a $25 gift card