TOPIC: Issue with PIX 515 Firewall

hello,

I set up my first PIX firewall (see config below) and a strange thing is happening. When i put a server behind it, the server could not get outbound access to the internet. Well, it had been a long day so i left everything on and left for the day. When i came back the next morning, the server was working just fine. It could browse and i could even use the RDP to contect to it remotely. So i added a second server and the same thing happened. It could not browse or get any outside access. So, i left if alone over night and sure enough the second server worked in the morning. The pix did not reboot during night nor did i make any changes over the two nights.

It seems like the pix took several hours to adjust or to 'learn' that the servers were present. Either that or the firewall fairy heard my pleas and magically fixed the problems each night.

Can any one offer any insight as to what is miss-configured or what is going on?


Here is my current Config:

PIX Version 7.2(1)
!
hostname FireWall
enable password 1AKCYK8Ghcq0czPj encrypted
no names
!
interface Ethernet0
speed 100
duplex full
nameif outside
security-level 0
ip address x.x.149.130 255.255.255.128
!
interface Ethernet1
speed 100
duplex full
nameif inside
security-level 100
ip address 192.168.2.1 255.255.255.0
!
interface Ethernet2
shutdown
no nameif
no security-level
no ip address
!
passwd 2KFQnbNIdI.2KYOU encrypted
no ftp mode passive
access-list outside_in extended permit tcp any host x.x.149.133 eq 3389
access-list outside_in extended permit tcp any host x.x.149.133 eq domain
access-list outside_in extended permit udp any host x.x.149.133 eq domain
access-list outside_in extended permit tcp any host x.x.149.131 eq domain
access-list outside_in extended permit udp any host x.x.149.131 eq domain
access-list outside_in extended permit tcp any host x.x.149.131 eq 3389
pager lines 24
logging trap warnings
mtu outside 1500
mtu inside 1500
asdm image flash:/asdm-512.bin
no asdm history enable
arp timeout 14400
global (outside) 1 x.x.149.132 netmask 255.255.255.255
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,outside) x.x.149.133 192.168.2.133 netmask 255.255.255.255
static (inside,outside) x.x.149.131 192.168.2.131 netmask 255.255.255.255
access-group outside_in in interface outside
route outside 0.0.0.0 0.0.0.0 x.x.149.129 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
no snmp-server location
no snmp-server contact
snmp-server community public
snmp-server enable traps snmp authentication linkup linkdown coldstart
snmp-server enable traps syslog
telnet 192.168.2.0 255.255.255.0 inside
telnet timeout 5
ssh timeout 5
console timeout 0
!
!
prompt hostname context
Cryptochecksum:c62713abff97948d5f20e2eff19a4f83
: end

This will be very interesting to see if you get a response to this. I have had similar issues with the Pix525 and Pix515. It ended up being issues on the switches that they were plugged into and all i did was reboot the switches to resolve.

I know that if you change the translations on the pix, you can have some issues unless you do a clear xlat. This may have also been the problem ?

It would be interesting if you could do further testing to see if you get simalar results as i got.

P.S. Its always best to remove ALL Username/PAsswords/Enable Passwords/Line Passwords, etc.. as there are tools out there that can convert the HASH back (or should i say brute force them)

CHeers

Wayne

Wayne,

Interestingly enough, thats the direction i was going with it.... i had just moved the servers from a switch in front of the firewall to one behind the firewall. i was wondering if the switch in front of the firewall, if the local arp table was still showing the servers connected to in and therefore not routing trafic properly to the PIX until the arp table refreshed.

i will experiment this weekend and post my results. Thanks for the help.

oh, and thanks for the tip about the hashed passwords, i did completely forget to remove them from my post.

Interestingly, i think i came across this issue again this morning. I have a Pix535 that i am installing into our network core to secure different legs of our network. I tried last week and had some issues with remote desktop not working over on of our legs. Today i tried and i lost connectivity from one of the network legs to another network legs.

Everything else works and other network legs can talk to the two problems segments of the network.

What i think has happened is, the router (well its an isa server) which is used down one of the WAN connections, hadn't updated its MAC entry and when it was trying to route to the other subnet it wasn't working as it was trying to get to the old routers MAC address instead of our new Pix535

Anyhow, we don't control the other side of the WAN so i am going to have to arrange some proper network downtime to do this where i can get someone available at the other end of the link to try and reboot their switches and firewall. Can only get this scheduled for two weeks time so gonna have to wait now

Cheers

Over the weekend i moved a few more servers behind the PIX. I moved my first one, and sure enough, it could not surf or get inbound connections. I rebooted the switch it was on (the one infront of the PIX) and bingo! the server could surf and get inbound trafic.

So I added a second server, same thing happened. This time i just left if alone and after a few hours, it did eventually surf and have inbound trafic. (after the switch's arp table expired?)

Added a third server, it couldnt get out, rebooted the switch and could surf right afterward.

Added a fourth computer, that had not been on the switch just to test, worked great, no problems, even with inbound trafic.

So i think thats what it was... the switch that the servers were on was not clearing its arp table fast enough, or at least thats what it seemed to be.

Hope this helps someone out there.

Yes, i have noticed some very strange things happen like this before. Just out of curiosity, what switch was it as I didn’t think that it took this long for the ARP entries to clear !

Glad someone else had the same issues as I have had, I originally wanted to understand why it was happening but was unable to find any details anywhere and just accepted it

Take it easy