PIX Issue

GhostlyPea

GhostlyPea

GhostlyPea

Soldato
Joined
30 Dec 2004
Posts
4,681
Location
Bromley, Kent
Morning all,

I've been passed a 515 to play with, currently has 7.0(1) running on it. Now I already have an older 501 running 6.3 and the commands (good for me as I can learn more) are different, with the 7.x

being based more on IOS.

The topology I'm using at the moment to test a few bits with is pretty simple:

lan -2650 -WAN- 515 -lan- laptop

The "WAN" side is using 55.55.55.0/28, inside LAN on the PIX is 10.2.2.0/24 and LAn on the rotuer is 10.1.1.0/24.

Unfortuantly I'm at work so I can't post the configs yet but I'm sure this is something simple.

Where I am at at the moment is that from the PIX I can ping through to 10.1.1.0 fine with return traffic and the laptop can ping the gateway (inside of FW). Esentially I know traffic is flowing mostly

right. The problem is when I try and ping through the FW or form the FW (inside) to anywhere else. The traffic isn't being permitted the return path. Now I know that echo-reply is blocked by default

so I tried these two methods:

http://www.cisco.com/en/US/products...oducts_tech_note09186a0080094e8a.shtml#topic0

I've copied the configuration exactly with no luck - debugs on the PIX show traffix is going through it and debugs onthe router show the traffic is returning to the PIX but just not getting through. I also

tried this with telnet (using an ACL permitting any any with no luck and also adding it to the global service policy with no luck) from the laptop to the routers LAN and WAN interface with no luck, which

doesnt seem right to be as I was under the impression that TCP return traffic was automatically permitted. I also have icmp permit echo and echo-reply commands entered from config mode.

The only thing I can think of is that I am trying to do this with no nat or global statements as I don't want to nat any traffic at the moment - could this be causing problems? Is a global/nat statement a

requirement? If so is there a way to allow traffic to return without it as I know it must be possible

Hope that makes sense, just shout if you need any more info and nay help is aprpeciated

Thanks!
 
Looking at some documents again - looks like a nat statement might be mandatory?

nat (inside) 0 any

and have nat-control enabled? not sure if a glabal address needs to be speficied even if it wont be used?

cheers

Edit: Reading more it seems that i want "no nat-control". this didnt seem to still permit return traffic though so Im still puzzeled
 
Last edited:
can you not telnet to it and grab the config?

I'm pretty rubbish at cisco LAN IOS (I'm a SAN man) but when its printed infront of me i can work it out :)
 
I can post it later - trouble is its at home in my lab, not production :(

Its really odd because as I understand it the stateful nature of the PIX means that with nat-control disabled I shouldnt need any translations or additional rules...it just doesnt want to seem to pass anything back through to the inside interface. For example a ping goes:

Host - inside int - outside int - router - back to outsid int and stops there

I don't have the additional commands on to permit echo-replies and its doing it to telnet/ssh also.

I had a 501 which I was running on 6.3 and that worked fine, same commands on here with nat-control enabled and it still doesnt work!

Ill se it up again alter and post the configs unless naybody has any bright info in the mean time
 
Right, excuse the wall of text.

This works:
pixfirewall(config)# sh run
: Saved
:
PIX Version 7.0(1)
names
!
interface Ethernet0
nameif OUTSIDE
security-level 0
ip address 55.55.55.2 255.255.255.240
!
interface Ethernet1
nameif INSIDE
security-level 100
ip address 10.2.2.1 255.255.255.0
!
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname pixfirewall
ftp mode passive
access-list IN extended permit tcp any any eq telnet
access-list IN extended permit tcp any any eq ssh
access-list IN extended permit icmp any any echo
access-list IN extended permit icmp any any echo-reply
access-list IN extended permit icmp any any unreachable
access-list IN extended permit icmp any any source-quench
access-list IN extended permit icmp any any time-exceeded
access-list NAT extended permit ip 10.2.2.0 255.255.255.0 host 66.66.66.66
access-list NONAT extended permit ip any any
pager lines 24
mtu OUTSIDE 1500
mtu INSIDE 1500
no failover
monitor-interface OUTSIDE
monitor-interface INSIDE
no asdm history enable
arp timeout 14400
nat-control
global (OUTSIDE) 1 interface
nat (INSIDE) 1 access-list NAT
nat (INSIDE) 1 0.0.0.0 0.0.0.0
access-group IN in interface OUTSIDE
route OUTSIDE 0.0.0.0 0.0.0.0 55.55.55.1 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
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp
telnet timeout 5
ssh timeout 5
console timeout 0
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
inspect dns maximum-length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp
!
service-policy global_policy global
Cryptochecksum:0164f627b244a5aa194aa14f23272c21
: end
Click to expand...

I know why it works and that's cool, however from what I can see I should be fine to remove the nat statements and the global statements and use the command "no nat-control". From what I can see tat should work but it doesn't and Im kind of stuck as Im not sure what I'm doing wrong
 
if nat-control is enabled you must have a nat statement in order for the traffic to be forwarded, NAT / NAT0 or otherwise.

If you disable nat-control and remove the nat statements it should still work.

Do you have a route back to the source network on the router that your sending icmp echo packets to? bear in mind that its being translated at the moment so itll be seen as coming from the address 55.55.55.2 ( in which case the router will reply because its on a directly connected network). if you remove the nat statements you'll need a route back to the 10.2.2.0/24 network on the router...

just setup a packet-capture and see what the packets are doing

access-list capture0001 line 1 permit icmp host 10.2.2.X host 55.55.55.1 echo
access-list capture0001 line 2 permit icmp host 55.55.55.55 host 10.2.2.X echo-reply

capture capture0001 access-list capture0001 interface INSIDE packet-length 1522

show capture capture0001 (To view packets in CLI)

http(s)://10.2.2.1/capture/capture0001/pcap (to download capture file)

open pcap in wireshark...

jobs a good one :)
 
$c8t@ said:
if nat-control is enabled you must have a nat statement in order for the traffic to be forwarded, NAT / NAT0 or otherwise.

If you disable nat-control and remove the nat statements it should still work.
Click to expand...

Yup, that's what I though...except it isn't working ;)

Do you have a route back to the source network on the router that your sending icmp echo packets to? bear in mind that its being translated at the moment so itll be seen as coming from the address 55.55.55.2 ( in which case the router will reply because its on a directly connected network). if you remove the nat statements you'll need a route back to the 10.2.2.0/24 network on the router...
Click to expand...

Routing is fine mate, the traffic just isnt being passed from out to in on the return trip

Thanks for the response though
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom