03-07-2006 06:56 PM - edited 03-09-2019 02:11 PM
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
names
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 192.168.111.3 format emblem
icmp permit any outside
icmp permit 192.168.111.0 255.255.255.0 inside
mtu outside 1500
mtu inside 1500
ip address outside xx.xx.xx.202 255.255.255.248
ip address inside 192.168.111.1 255.255.255.0
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 192.168.111.0 255.255.255.0 0 0
static (inside,outside) xx.xx.xx.204 192.168.111.2 netmask 255.255.255.255 0 0
static (inside,outside) xx.xx.xx.205 192.168.111.3 netmask 255.255.255.255 0 0
static (inside,outside) xx.xx.xx.206 192.168.111.4 netmask 255.255.255.255 0 0
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 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 192.168.111.0 255.255.255.0 inside
floodguard enable
telnet timeout 5
ssh 192.168.111.0 255.255.255.0 inside
ssh timeout 5
console timeout 0
03-10-2006 09:20 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide