IPSec Tunnel & DMZ

[LNavaraj]

Hi, Will PIX 515 allow Packets coming through IPSec tunnel, from the outside interface to the DMZ interface? Have any idea?

Securiy levels of the interfaces are as follows.

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 intf2 security10

[kdurrett]

Are you talking about terminating the tunnel on the pix so you can talk to the dmz? Sure can. Are you talking about terminating IPSEC on a device within the dmz. Sure can. Its set up the exact same way as if going to the inside interface as in http://www.cisco.com/warp/public/110/pixpixvpn.html if terminating on the pix. If terminating on device inside dmz you'll need 3 things.

1. Static NAT translation for that device. This is required.

2. Open up udp 500 inbound, if you want the remote side to be able to initiate the connection

3. Open up ESP inbound. This is required.

Kurtis Durrett

[LNavaraj]

Thanks for your response. I am talking about terminating the tunnel on the pix itself. In my case, I need to route packets from my inside interface & also from my outside interface ( coming through tunnel) to the DMZ interface. Let me give a shot.

[kdurrett]

As long as its directly connected you should need any routes. On the dmz you will need to set up nat 0 to deny nat from your dmz network to the remote vpn network. If you need to allow the inside to go the dmz, then you'll need to set up some type of nat there as well, with an access-group on the dmz to allow the traffic initiated from the dmz in, if thats what you need.

Kurtis Durrett

[LNavaraj]

Here is my PIX config. My DMZ host IP is 192.168.22.20 which is connected through intf2. I am able to access this DMZ host from my internal Net 10.3.111.0 but not from my remote VPN Net 10.3.9.0. Let me know if you have any clue. Thanx much..

NB: The VPN tunnel is working fine.

access-list 160 deny ip 10.3.111.0 255.255.255.0 host 192.168.22.20

access-list 160 permit ip 10.3.111.0 255.255.255.0 10.3.9.0 255.255.255.0

access-list 160 permit ip host 192.168.22.20 10.3.9.0 255.255.255.0

access-list 170 permit ip host 192.168.22.20 10.3.111.0 255.255.255.0

access-list 170 permit ip host 192.168.22.20 10.3.9.0 255.255.255.0

ip address outside 64.1.81.13 255.255.255.240

ip address inside 10.3.111.1 255.255.255.0

ip address intf2 10.4.120.1 255.255.255.0

ip address intf3 127.0.0.1 255.255.255.255

ip address intf4 127.0.0.1 255.255.255.255

ip address intf5 127.0.0.1 255.255.255.255

nat (inside) 0 access-list 160

static (inside,intf2) 10.3.111.0 10.3.111.0 netmask 255.255.255.0 0 0

access-group 170 in interface intf2

route outside 0.0.0.0 0.0.0.0 64.1.81.1 1

route intf2 192.168.22.20 255.255.255.255 10.4.120.2 1

sysopt connection permit-ipsec

sysopt route dnat

crypto ipsec transform-set dsltest esp-des esp-md5-hmac

crypto map dsl 160 ipsec-isakmp

crypto map dsl 160 match address 160

crypto map dsl 160 set peer 192.168.40.30

crypto map dsl 160 set transform-set dsltest

crypto map dsl interface outside

isakmp enable outside

isakmp key mykey address 192.168.40.30 netmask 255.255.255.255

isakmp identity address

isakmp policy 160 authentication pre-share

isakmp policy 160 encryption des

isakmp policy 160 hash md5

isakmp policy 160 group 1

isakmp policy 160 lifetime 86400

[kdurrett · Accepted solution]

Restate what you are doing is that you want your dmz and your inside interface subnets to be able to talk to the remote network through the vpn tunnel. Your inside is 10.3.111.0/24 and your intf2 is 10.4.120.0/24 and your remote network that you want to talk to across the tunnel located at peer 192.168.40.30 which is located on your outside interface. You also have a single host 192.168.22.20 located on intf2 that you want to go across the tunnel. But you dont want your directly connect intf2 to actually go across the tunnel, just the single host located of that int. So you are doing a lab set up with this? Your peers ip address is a private address is why im asking and to verify. Its inside network is 10.3.9.0/24.

Your gonna have to clarify a few things here for me. From crypto map dsl you have a match address of 160 which is:

access-list 160 deny ip 10.3.111.0 255.255.255.0 host 192.168.22.20

access-list 160 permit ip 10.3.111.0 255.255.255.0 10.3.9.0 255.255.255.0

access-list 160 permit ip host 192.168.22.20 10.3.9.0 255.255.255.0

You dont need your deny statement, if its not permitted, its not going. Your interesting traffic access-list should read should read:

access-list 160 permit ip 10.3.111.0 255.255.255.0 10.3.9.0 255.255.255.0

access-list 160 permit ip host 192.168.22.20 10.3.9.0 255.255.255.0

You also have this same access-list tied to you "nat (inside) 0" which has to change.

You are missing your "nat (intf2) 0" statement though and we need to have separate access list for each nat statement. So do like this:

access-list nonat permit ip 10.3.111.0 255.255.255.0 10.3.9.0 255.255.255.0

nat (inside) 0 access-list nonat

access-list nonatintf2 permit ip host 192.168.22.20 10.3.9.0 255.255.255.0

nat (intf2) 0 access-list nonatintf2

Do a clear xlate, wr mem and a reload. Test it again. Should be working. FYI, don't remove access-list 160 without first unapplying your crypto map or you will lock up your pix.

Kurtis Durrett

[LNavaraj]

Yes it is working fine, I just added the statement "nat (intf2) 0 access-list 160" in my current config without altering anything else and i am able to access the DMZ host from the remote VPN net (10.3.9.0). I don't think we need to have two separate access-lists for the tunnel. I attached the working config along with this.

After seeing your explanation only I realized that I was missing the nat 0 statement for intf2. Sorry that i couldn't explain my situation clearly. Of course i am trying this in a lab setup and thatz why I used private IP addresses.

Let me give an explanation for the deny statement "access-list 160 deny ip 10.3.111.0 255.255.255.0 host 192.168.22.20"

In my real situation I’ve got to use "any" instead 10.3.9.0 as a remote net. So i need to deny the traffic for the host 192.168.22.20 from my inside net. I forgot to take out that statement while posting.

My kind thanks to you for all the help you rendered without loosing your temper. Appreciate your patience. Here is the current working config. Feel free to let me know if you feel anything odd in this config.

access-list 160 deny ip 10.3.111.0 255.255.255.0 host 192.168.22.20

access-list 160 permit ip 10.3.111.0 255.255.255.0 any

access-list 160 permit ip host 192.168.22.20 10.3.9.0 255.255.255.0

access-list 170 permit ip host 192.168.22.20 10.3.111.0 255.255.255.0

access-list 170 permit ip host 192.168.22.20 10.3.9.0 255.255.255.0

ip address outside 64.1.81.13 255.255.255.240

ip address inside 10.3.111.1 255.255.255.0

ip address intf2 10.4.120.1 255.255.255.0

ip address intf3 127.0.0.1 255.255.255.255

ip address intf4 127.0.0.1 255.255.255.255

ip address intf5 127.0.0.1 255.255.255.255

nat (inside) 0 access-list 160

nat (intf2) 0 access-list 160

static (inside,intf2) 10.3.111.0 10.3.111.0 netmask 255.255.255.0 0 0

access-group 170 in interface intf2

route outside 0.0.0.0 0.0.0.0 64.1.81.1 1

route intf2 192.168.22.20 255.255.255.255 10.4.120.2 1

sysopt connection permit-ipsec

sysopt route dnat

crypto ipsec transform-set dsltest esp-des esp-md5-hmac

crypto map dsl 160 ipsec-isakmp

crypto map dsl 160 match address 160

crypto map dsl 160 set peer 192.168.40.30

crypto map dsl 160 set transform-set dsltest

crypto map dsl interface outside

isakmp enable outside

isakmp key mykey address 192.168.40.30 netmask 255.255.255.255

isakmp identity address

isakmp policy 160 authentication pre-share

isakmp policy 160 encryption des

isakmp policy 160 hash md5

isakmp policy 160 group 1

isakmp policy 160 lifetime 86400

[kdurrett]

Glad to hear its working. Usually its a good idea to keep things separate like your access-list because if you add another remote peer, your gonna have to redo the whole thing. So its best practice to just start out that way. FYI, its recommended that you do not use the keyword "any" in your interesting traffic access list when using ipsec. I've never really had a problem with it on a router, but the pix is a different story.

Kurtis