Solved

Cisco PIX 515

Posted on 2015-01-14
9
308 Views
Last Modified: 2015-01-15
This config has been running on this pix for a number of years with minor modifications over the years, additional access-lists, change in ISP, etc.  Everything has been just fine.

Over the past week, the access-list and static translations to a specific network (across a MPLS link) has quit forwarding traffic.  Specifically, to the 192.168.107.x network.  
The PIX can ping all devices on the .107.x network and those devices can ping the PIX.  The .107.x network is across the MPLS links.  All other translations in the PIX are working okay.  Just the .107.x network.

All devices can be access internally across MPLS link on specific ports defined here in the PIX.  So in can use tightVNC from 192.168.102.x network to a PC on the 192.168.107.x network but from the outside using 66.xx.xxx.9, it fails.

Can you see why?  I cannot see it.  Nothing has changed...PIX has been rebooted.

I could not figure out how to turn the logs on for logging the NAT translation.  Got debug logging working but never saw any detail like I expected.


Thanks for any input - very much appreciated.



PIX01# sh run
: Saved
:
PIX Version 6.3(4)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security4
enable password l7GOy63pGwt7P979 encrypted
passwd l7GOy63pGwt7P979 encrypted
hostname PIX01
domain-name name.Com
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 101 permit icmp any any echo-reply
access-list 101 permit icmp any any source-quench
access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 permit tcp 64.18.0.0 255.255.240.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp any host 66.xx.xxx.2 eq www
access-list 101 permit tcp any host 66.xx.xxx.2 eq https
access-list 101 permit tcp any host 66.xx.xxx.3 eq 3389
access-list 101 permit tcp any host 66.xx.xxx.4 eq 3389
access-list 101 permit tcp any host 66.xx.xxx.5 eq www
access-list 101 permit tcp any host 66.xx.xxx.5 eq 5500
access-list 101 permit tcp any host 66.xx.xxx.5 eq 5800
access-list 101 permit tcp any host 66.xx.xxx.5 eq 5900
access-list 101 permit tcp any host 66.xx.xxx.6 eq 3389
access-list 101 permit tcp any host 66.xx.xxx.7 eq 8016
access-list 101 permit tcp any host 66.xx.xxx.7 eq 8200
access-list 101 permit tcp any host 66.xx.xxx.7 eq 8201
access-list 101 permit tcp any host 66.xx.xxx.7 eq 10019
access-list 101 permit tcp any host 66.xx.xxx.7 eq 12088
access-list 101 permit tcp any host 66.xx.xxx.8 eq 9001
access-list 101 permit tcp any host 66.xx.xxx.8 eq 9002
access-list 101 permit tcp any host 66.xx.xxx.10 eq 5900
access-list 101 permit tcp any host 66.xx.xxx.9 eq 5900
access-list 101 permit tcp any host 66.xx.xxx.8 eq www
access-list 101 permit tcp any host 66.xx.xxx.11 eq 3389
access-list 101 permit tcp any host 66.xx.xxx.12 eq www
access-list 101 permit tcp any host 66.xx.xxx.13 eq www
access-list 101 permit tcp 64.233.160.0 255.255.224.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp 66.249.80.0 255.255.240.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp 72.14.192.0 255.255.192.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp 209.85.128.0 255.255.128.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp 66.102.0.0 255.255.240.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp 74.125.0.0 255.255.0.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp 207.126.144.0 255.255.240.0 host 66.xx.xxx.2 eq smtp
access-list 101 permit tcp 173.194.0.0 255.255.0.0 host 66.xx.xxx.2 eq smtp
access-list in2out permit ip any any
access-list in2out deny tcp any any eq smtp
access-list in2out permit tcp host 192.168.102.21 any eq smtp
access-list InToOut permit tcp host 192.168.102.21 any eq smtp
access-list InToOut deny tcp any any eq smtp
access-list InToOut permit ip any any
pager lines 24
icmp deny any outside
mtu outside 1500
mtu inside 1500
mtu intf2 1500
ip address outside 66.xx.xxx.2 255.255.255.240
ip address inside 192.168.102.3 255.255.255.0
ip address intf2 172.16.1.254 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
nat (intf2) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface smtp 192.168.102.21 smtp netmask 255.255.
55.255 0 0
static (inside,outside) tcp interface www 192.168.102.21 www netmask 255.255.25
.255 0 0
static (inside,outside) tcp interface https 192.168.102.21 https netmask 255.25
.255.255 0 0
static (inside,outside) 66.xx.xxx.3 192.168.102.22 netmask 255.255.255.255 0 0
static (inside,outside) 66.xx.xxx.4 192.168.107.8 netmask 255.255.255.255 0 0
static (inside,outside) 66.xx.xxx.5 192.168.107.8 netmask 255.255.255.255 0 0
static (inside,outside) 66.xx.xxx.6 192.168.102.24 netmask 255.255.255.255 0 0
static (inside,outside) 66.xx.xxx.7 192.168.103.219 netmask 255.255.255.255 0 0
static (inside,outside) 66.xx.xxx.8 192.168.107.223 netmask 255.255.255.255 0 0
static (inside,outside) 66.xx.xxx.9 192.168.107.224 netmask 255.255.255.255 0 0
static (inside,outside) 66.xx.xxx.10 192.168.103.224 netmask 255.255.255.255 0
static (inside,outside) 66.xx.xxx.11 192.168.103.227 netmask 255.255.255.255 0
static (inside,outside) 66.xx.xxx.12 192.168.103.228 netmask 255.255.255.255 0
static (inside,outside) 66.xx.xxx.13 192.168.103.229 netmask 255.255.255.255 0
access-group 101 in interface outside
access-group InToOut in interface inside
route outside 0.0.0.0 0.0.0.0 66.xx.xxx.1 1
route inside 172.16.102.0 255.255.255.0 192.168.102.1 1
route inside 172.16.103.0 255.255.255.0 192.168.102.1 1
route inside 172.16.104.0 255.255.255.0 192.168.102.1 1
route inside 172.16.105.0 255.255.255.0 192.168.102.1 1
route inside 192.168.103.0 255.255.255.0 192.168.102.1 1
route inside 192.168.104.0 255.255.255.0 192.168.102.1 1
route inside 192.168.105.0 255.255.255.0 192.168.102.1 1
route inside 192.168.107.0 255.255.255.0 192.168.102.1 1
route inside 192.168.150.4 255.255.255.252 192.168.102.1 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 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.102.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
sysopt connection permit-pptp
telnet 192.168.102.0 255.255.255.0 inside
telnet timeout 5
ssh timeout 5
management-access inside
console timeout 0
terminal width 80
Cryptochecksum:124472c12a4ca43fb36369be754533e1
: end
PIX01#
0
Comment
Question by:RFloyd30
  • 5
  • 4
9 Comments
 
LVL 15

Expert Comment

by:max_the_king
Comment Utility
Hi,
first of all there is something unusual in your configuration, because i see a nat exemption:
nat (inside) 0 access-list nonat
but i cannot see any "access-list nonat" statement ! That may be a problem should you need to exempt NAT on "107! subnet, unless you just forgot to post it on this thread.

Then, if Pix is no longer natting those *.107 hosts, and you haven't changed anything on the pix, I would make sure that nothing has changed on the router 192.168.102.1, which must provide the route back to the pix.

hope this helps
max
0
 

Author Comment

by:RFloyd30
Comment Utility
Thanks Max

Those statements we're remove and we setup for a VPN connection and some translations to a VoIP system. They are no longer used and I removed them for this post
Since all this works internally and I've traced the routes manually I don't see the routing being an issue. There was one change on the 107 side as we turned up an internet connection via the MPLS with a software firewall am twined by the MPLS vendor.  But the devices on that subnet that are in question are still using their normal default gateway and thus still browse the web gong across the MPLS via the 102 network.  The only routing tables I cannot see are the MPLS routers but since all the translated protocols work internally it only seems the problem is from the outside in. Of course all the 107 devices can ping this pix.
0
 
LVL 15

Expert Comment

by:max_the_king
Comment Utility
then chances are that the order of nat is messing up your rules with unexpected behaviour.
To be sure of that, you should avoid to use
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
(i always avoid that like plague !)

replace that with

no nat (inside) 1 0.0.0.0 0.0.0.0 0 0
nat (inside) 1 192.168.102.0 255.255.255.0

then do a
clear xlate

and finally try to access your hosts from outside

it is worth a try
hope this helps
max
0
 

Author Comment

by:RFloyd30
Comment Utility
Thanks I will try this. Question though, would I also nat the other networks that the pix is translating to like the .107 and .103 networks specifically?
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 15

Expert Comment

by:max_the_king
Comment Utility
yes, you just need to nat separately, but you can associate that to the same global, i.e.:

nat (inside) 1 192.168.103.0 255.255.255.0

my advice is to avoid nat on 107 subnet, just the time you need to check if your outside access is working.

Then you should analyze why you need nat to get to 107 subnet, because that is usually provided from the mpls router. In that case you should include the 107 subnet into the access-list nonat.

max
0
 

Author Comment

by:RFloyd30
Comment Utility
Ok, I'm a bit confused.  Of course, the Cisco world can be a bit different from others like Sonicwall, watchguard, etc...
Sorry to be hard headed and thank you for you time and explanation!!!

I'm in the mindset that I would need to NAT anything coming from the outside to the inside.
So I would think I need to have 3 NAT statements like your example, one for the .102, .103 and .107 since I'm coming from the outside public IP's to the inside private IP's.  The MPLS routes are all private meaning that they all are on the inside of the PIX.

And why all of a sudden because the translation from the Outside to the Inside on networks .102 and .103 all work.  Its just picking on the .107 network which led me to ask, what changed.  The only change was the Internet out link which is new on the other side of the MPLS network (.107).  So I thought it was a routing issue.  But if it works inside from .102 to .107 and the tcp ports answer, in my mind routing appears okay plus all ports are ok because they respond.

 Thanks again,
0
 
LVL 15

Accepted Solution

by:
max_the_king earned 500 total points
Comment Utility
Well, now you said it all !
The only change was the Internet out link which is new on the other side of the MPLS network (.107).

that router, the one on the other side of the MPLS network, is talking to the MPLS router on your side, and it must have some rules pointing to the public IP of the MPLS router. This means that the problem is into  MPLS router, although only for what is concerning the public ip addresses, and that is why your internal lan are working. Tipically, your ISP must set the public IP you're using to nat remotely, to BOTH the MPLS routers,  as "ROUTABLE", that is: visible on the internet.

By the way, what i posted before is still valid and you can do it later, AFTER solving MPLS issue, which is more likely the problem.

nat (inside) 1 192.168.102.0 255.255.255.0
nat (inside) 1 192.168.103.0 255.255.255.0
nat (inside) 1 192.168.107.0 255.255.255.0

global (outside) 1 interface

is really just "one nat" which you are splitting into 3 statements: this way you avoid using "nat any" which is ambigous especially when you're debugging

max
0
 

Author Closing Comment

by:RFloyd30
Comment Utility
Problem is solved.  The PIX was not the issue as I thought.  Again, the reason I thought the PIX was the issue was because the internet networks, for example from .102.x (pix is .102.3) could ping all devices on .107.x and all my translates in the pix worked too.  Only from the Outside they did not work.
Maybe you can respond one me time and clear up something for me.  Our MPLS routers don't have any Public IP's on them, even the WAN interfaces.  The only way I see this because they are managed and I cannot get a RUN from them is to perform a trace route from the .102.x network to the .107.x network and see their 10.x.x.x networks in the middle of the trace.

The solution was this.  Yes we added a router (managed) in the .107 network for direct internet access, which was the only change.  On a voice router in the .107 network was the default gateway - .107.1.  When this new internet router was added, I made the default route for this .107.1 router (0.0.0.0 0.0.0.0) to be the new internet router, .107.10.   I changed this back to the MPLS router, .107.5 cleared the xlate in the PIX and it works like it did before.

So again my question, why would it work from the internal LAN, .102.x to .107.x but not when it came in from the PIX even though the PIX could see these devices across the internal WAN (MPLS)....  That is the piece I'm missing.

Thank you again!!!
0
 
LVL 15

Expert Comment

by:max_the_king
Comment Utility
Our MPLS routers don't have any Public IP's on them, even the WAN interfaces.
this is managed by ISP; the private ip on MPLS Wan interface are natted by ISP directly, you'll never see them.

why would it work from the internal LAN,  .102.x to .107.x but not when it came in from the PIX even though the PIX could see these devices across the internal WAN (MPLS)....
because the pix is seeing MPLS router as direct attached, on its inside interface.
On the contrary, your hosts are natted on public IP that Pix try to manage, but MPLS router do not route those public IP to the WAN where the pix is connected.
This is due to a change in MPLS router which is probably routing only old (and useless) public IP addresses.

max
0

Featured Post

What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

If you have an ASA5510 then this sort of thing would be better handled with a CSC Module, however on an ASA5505 thats not an option, and if you want to throw in a quick solution to stop your staff going to facebook during work time, then this is the…
Creating an OSPF network that automatically (dynamically) reroutes network traffic over other connections to prevent network downtime.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now