Pix515e routing question... 2

[LedZepRock]

Hi

There is a big hole in my knowledge, and I cant see what I a missing.... the question

Setup

FTP Server (1.1.1.2)
ISDN Router (1.1.1.1)
|
ISDN Router (2.2.2.2)
Checkpoint Firewall (2.2.2.1)
|
VPN
|
PIX 515e Firewall (3.3.3.1)
FTP Client (3.3.3.2)

So when I enter the command ftp 1.1.1.2 this packet has to some how arrive at the FTP server, the default route on the PIX is the internet router, how to I configure the PIX to understand that the ftp server 1.1.1.2 is down the VPN connection to 2.2.2.1??

Does that make sense, I hope so, please ask if I have missed something, I really need to get this sorted out fast...

Thanks
Simon

 

[LedZepRock]

Thinking some more...

Should it be as easy as adding this command???

route outside 1.1.1.2 255.255.255.255 2.2.2.2

would that get the packet as far as the ISDN router???

 

[rudeboy]

You have to make sure that the PIX sees it as "interesting" traffic. This is done with crypto map statements and access-lists. Please post your PIX config. This will help others advise you on to what lines you need added to your config.

 

[LedZepRock]

Thanks rudeboy for the help... I set this PIX up about a year ago, and you talking about the "interesting traffic" jogged my memory on that, the config is quite long on this pix and I would rather not post it in full, but here are the
best bits, as you can see I have my home lan (lan) and the hosted dmz (hdmz), the VPN works fine between those, but that ISDN router I am trying to get to is on the "hdmz", I have added what I thought would work (ie added the new address to the object group) but currently my tracert's still end up on the internet rather than down the VPN...

If this below does not help please let me know and I will post more config....

(Group)
object-group network live_subnet
network-object hdmz 255.255.255.0
network-object 62.186.7.0 255.255.255.0

(No NAT rules)
access-list nonatinside permit ip lan 255.255.255.0 hdmz 255.255.255.0

(Access-Lists)
access-list inside_in permit ip lan 255.255.255.0 hdmz 255.255.255.0

(Intesting Traffic)
access-list hdmz_10 permit ip lan 255.255.255.0 object-group live_subnet

(Crypto Stuff)
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 10 ipsec-isakmp
crypto map outside_map 10 match address hdmz_10
crypto map outside_map 10 set pfs
crypto map outside_map 10 set peer ***.101.163.15
crypto map outside_map 10 set transform-set ESP-3DES-SHA

 

[rudeboy]

If you have it set as intersting traffic and the tunnel is up, it should go through the tunnel. Does your interesting traffic match on both sides?(Both ends of the tunnel permit the same subnet/hosts through) On the PIX, you are permitting the "lan" to the object-group live_subnet. On the other end of the tunnel you should be permitting live_subnet to the "lan

 

[LedZepRock]

Rudeboy

Thanks from all your help on this, soon as you said interesting traffic I it all made sense, the config I posted above did work, but I then had a small problem with my testing
(used the wrong ip ) but it is fine now. The main thing I found difficult here though was debuging the traffic, this tunnel is always up so "debug isakmp" and so on show nothing about this traffic. What debug would show me if this packet was classed as "interesting"???

Thanks again

 

[308win]

Here are three ways to see traffic:

1) see if you trigger the appropriate ACL

stlouis-pix# sho access-l acl-nat
access-list acl-nat; 10 elements
access-list acl-nat line 1 permit ip net-stlouis 255.255.255.0 net-192-privates 255.255.0.0 (hitcnt=64436)

2) See exactly what triggered it by setting up a capture with the same acl.

capture nat access-l acl-nat interface inside

sho capture nat
779 packets captured
07:54:41.395227 192.168.9.7.1034 > 192.168.85.45.2967: udp 28
07:54:41.540133 192.168.9.7.1034 > 192.168.85.45.2967: udp 28


3) See that it was encapsulated/encrypted, check the remote end for decap/decrypt and ensuing encap/encrypt of return traffic.

sho cry ip sa
local ident (addr/mask/prot/port): (net-stlouis/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (net-192-privates/255.255.0.0/0/0)
current_peer: x.y.com:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 3105647, #pkts encrypt: 3105647, #pkts digest 3105647
#pkts decaps: 2180859, #pkts decrypt: 2180859, #pkts verify 2180859
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 5, #recv errors 0

 

[LedZepRock]

Thanks, those will really help..

Ta