506E multiple issues

Unanswered Question
Mar 7th, 2006
User Badges:

Below is a copy of the current running config. We have several issues. The device is a 506E purchased 2 weeks ago.

First, behind this firewall, I can not connect to another office using Remotely Anywhere (uses Java on port 2000). The webpage loads but the jave applet just hangs. Yet when I swap out the PIX with the old firewall (m0n0wall/FreeBSD) I have no issues. The current config is also almost the same as another office where I have no issues connecting to a Remotely Anywhere session.

Second, for some reason the PIX would not allow in/out access if the outside address was xx.xx.xx.204 with the static map to the webserver at xx.xx.xx.202. Once I swapped those everything works. Why would it matter which IP address is used?

Lastly, I configured this PIX via the terminal. Added in the access list. Upon testing I found out that inbound traffic was not working to any internal server (i.e. http). I opened up the PDM and from there saw there was nothing listed in the access list. I did a refresh to make sure . I then deleted on the terminal the ACLs and added them in via the PDM. Once that was saved I could have someone connect from the outside to the webserver. Looking at the config from the terminal, the lines are EXACTLY the same! What in the world would cause the PIX to ignore the what is in the terminal and follow that only which is inserted via the PDM? Makes no sense since in the end the PIX follows the config, so that really confuses me.


PIX Version 6.3(5)

interface ethernet0 auto

interface ethernet1 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

fixup protocol dns maximum-length 512

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

fixup protocol http 80

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol sip 5060

fixup protocol sip udp 5060

fixup protocol skinny 2000

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol tftp 69


access-list outside_access_in permit tcp any host xx.xx.xx.204 eq www

access-list outside_access_in permit tcp any host xx.xx.xx.205 eq www

access-list outside_access_in permit tcp any host xx.xx.xx.204 eq smtp

access-list outside_access_in permit tcp any host xx.xx.xx.204 eq imap4

access-list outside_access_in permit tcp any host xx.xx.xx.204 eq pop3

access-list outside_access_in permit tcp any host xx.xx.xx.204 eq https

pager lines 24

logging timestamp

logging host inside format emblem

icmp permit any outside

icmp permit inside

mtu outside 1500

mtu inside 1500

ip address outside xx.xx.xx.202

ip address inside

ip audit info action alarm

ip audit attack action alarm

pdm history enable

arp timeout 14400

global (outside) 1 xx.xx.xx.203

nat (inside) 1 0 0

static (inside,outside) xx.xx.xx.204 netmask 0 0

static (inside,outside) xx.xx.xx.205 netmask 0 0

static (inside,outside) xx.xx.xx.206 netmask 0 0

access-group outside_access_in in interface outside

route outside xx.xx.xx.201 1

timeout xlate 3:00: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

http server enable

http inside

floodguard enable

telnet timeout 5

ssh inside

ssh timeout 5

console timeout 0

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

Your first issue appears to be the Java applet is not getting back across the firewall. I am not sure why this would be happening, hopefully someone else can shed some light on this. Maybe you could do some debugs on that traffic and post it up?

The second issue could be related to the ISP (or your outside router) default route, likely pointed to the .202 address. (most ISP's will use the first IP in the range for the assumed gateway)

The last issue (I have done this before) may have been a typo on the access-group command, possibly a hyphen instead of an underscore? One letter or symbol that doesn't match and the ACL will not match the access-group, and it does not give you an error!

Hope this helps some.


This Discussion