Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PIX 515 only translating for outside interface address (even w/static)

Status
Not open for further replies.

jspotts

IS-IT--Management
Mar 6, 2003
3
US
Ok so I'm at my wits end with this problem here and I honestly think this issue is a deeper, non-user, problem. I am the LAN Admin for the Minnesota Daily and our old PIX had the bug where too much traffic crashed it. So we just got the replacement from cisco and I used this opportunity to rebuild the PIX to a cleaner config on the newest FOS 6.3, with newest PDM. I test this config with the old PIX (FOS 6.2(1), PDM 2.2) and it works nicely, on the new PIX though it won't hear outside incoming traffic to any address but the outside interface. I have the static and access-lists defined to allow traffic to come into 128.101.178.1 and translate to 192.168.0.1 for web and smtp. The outside interface is 128.101.178.253 and the router is 128.101.178.254 (we own the whole 128.101.178.0/24 subnet). See below for my config file.

What I've tried:
- Using the old PIX's config (which is rather dirty since the former LAN Admin didn't keep it in good shape)
- Clearing the ARP table on the outside router (just in case it was the problem)
- "debug icmp trace" and watched as the new PIX translated out just fine and I even used a remote site that I controlled to watch for the ping, which was recieved and an echo was sent, but never recieved by the new PIX.

The old PIX does this all just fine, it accepts traffic in at the outside address (also .253) for PAT for all the other machines inside, and translates and accepts traffic for .1 outside for the Mail/webMail server.

I hope I'm making sense, since this problem is not making any sense to me at all. I've been working with Cisco almost since day one and their tech doesn't seem to understand the problem at all, that or just doesn't seem to be giving me any good suggestions.

Just an FYI this is a config I found that is almost identical to my setup < and I've compared mine and it dozens of times just to &quot;make sure.&quot;


-----------------------------------------------------------
PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password XXXXXXXXXX encrypted
passwd XXXXXXXXXXX encrypted
hostname pixfirewall
domain-name mndaily.com
clock timezone CST -6
clock summer-time CDT recurring
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
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
names
name 128.101.178.1 Mail
name 192.168.0.1 Romulus
name 192.168.0.0 Inside
access-list 100 permit icmp any any
access-list 100 permit tcp any host Mail eq www
access-list 100 permit tcp any host Mail eq smtp
pager lines 24
logging trap debugging
logging host inside 192.168.0.11
mtu outside 1500
mtu inside 1500
ip address outside 128.101.178.253 255.255.255.0
ip address inside 192.168.0.254 255.255.255.0
ip verify reverse-path interface inside
ip audit info action alarm
ip audit attack action alarm
ip local pool DailyVPN 192.168.0.30-192.168.0.49
pdm location Romulus 255.255.255.255 inside
pdm location 192.168.0.11 255.255.255.255 inside
pdm location Mail 255.255.255.255 outside
pdm logging debugging 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) Mail Romulus netmask 255.255.255.255 0 0
access-group 100 in interface outside
route outside 0.0.0.0 0.0.0.0 128.101.178.254 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 uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 192.168.0.11 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
no floodguard enable
sysopt connection permit-pptp
sysopt noproxyarp outside
sysopt noproxyarp inside
service resetinbound
telnet 192.168.0.11 255.255.255.255 inside
telnet timeout 5
ssh Inside 255.255.255.0 inside
ssh timeout 5
console timeout 0
dhcpd address 192.168.0.50-192.168.0.200 inside
dhcpd dns 192.168.0.10 128.101.101.101
dhcpd wins 192.168.0.10
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd domain mndaily.com
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Cryptochecksum:XXXXXXXXXXXXXXXXXXXXXXXXX
: end
 
Have you tried this without the `ip verify reverse-path interface inside' anti spoofing feature? Use no ip verify reverse-path interface inside to remove.

The manual indicates that for this command to work routing must be fully specified, and I see from your config there is no route inside statement, in your application you dont need one. This may be grabing at straws, but its a possibility?

Check for dropped packets with the show interface command, entries may appear under `unicast rpf drops'


 
I'll give that a go routerman. Anything that I can try at this point I will. The tighter I can make my config the more solid my testing can be.

Thanks for a good starting suggestion. Anyone with more ideas? If I haven't tried it yet I'll be willing to give it a go.
 
HI.

> test this config with the old PIX
> - Clearing the ARP table on the outside router.
Did you clear the ARP again after placing the old pix for testing?
Try to check the arp cache on the router &quot;sh ip arp&quot; - it really looks like ARP related issue. Try to power cycle the router to be on the even safer side.

> logging trap debugging
> logging host inside 192.168.0.11
So - did you check the logs?
Any relevant messages?

You can also add:
logging buffer 4
Which will show only denied traffic using:
show log

Bye


Yizhar Hurwitz
 
Issue was resolved. The problem was the config line &quot;sysopt noproxyarp outside&quot;. This command line is a bit vague in the documentation so I over looked it multiple times. The Cisco tech support person assigned to my case obviously hadn't looked over the config I sent him since a read through would have revealed this as the problem (accoarding to my contact at the University network we are attached to). Oh well. Case resolved and frustrations over.

So for future reference, if you are having a problem with ARP tables on the router just outside your firewall (or on the inside) look for the config line sysopt noarpproxy and remove it in any of its forms.

Thanks to the two who offered advice you both at least got me looking in the right direction.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top