PIX 501, VPN Tunnel, DHCPRelay

[lmjackson]

Have established a VPN tunnel with a Cisco concentrator and the PIX 501. I need to be able to get an IP address, DNS, WINs from a server on the inside of the VPN Concentrator. Believe I need to use DHCPRelay - Agent or Server? Any help would be greatly appreciated.

[madube_vtl]

Hello,

In my case, I have found the problem.

My network design has the PIX 501 as Eazy VPN client connecting to the VPN3000 which is the Eazy VPN server. The DHCP server is behind the VPN 3000.

My problem was caused but the vpnclient management clear command. If you remove this command, then another pair of SAs (inbound/outbound) gets created with the Public IP of the PIX 501 as source ip with the proper access-list that defines what will be encrypted in the tunnel. Then the DHCP request is relayed into the IPSEC tunnel.

When the command is there, only one pair of SAs gets created with the Local LAN as source IP. That is why the DHCP request was not encrypted into the tunnel.

Hope it helps you

[bswitzer]

Thanks for your note, that's reassuring.

What is the 'vpnclient management clear command'?

'Public IP of the PIX 501' ... I take it then that the VPN Concentrator understands to send this through the tunnel - otherwise, given the public IP address, would it not go out over the public net.?

[b_switzer]

OK, found it. Sorry about that, my printed docs aren't 6.3, and I'm not used to Cisco commands being so ... long.

If I'm reading this right, all management occurs via tunnels. The management tunnel command allows the control of 'which' networks that can participate in the tunnel, can manage. Confirm please?

So ... just what is management access? telnet, ssh, syslog, and the like? i.e. everything that comes with 'management-access inside'?

The thread originator solved his problem with clear, which implies he was tunneled before. I would not have thought DHCP relay to be 'management', and the dhcp relay problem thus solved by clearing it.

[Since I have not specified management, and the default is clear, I assume vpnc manage is not an issue in my current dhcpr relay problem.]

Given that I have a large base of largely clueless users, and there are decent passwords on the 501's themselves, my quick read of management tunnel is I don't need it. (But I can see where it would be useful.)

Reading http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/config/pixclnt.htm#wp1079798, particularly "To completely prevent remote management using the outside interface of your PIX Firewall, enter the following command: vpnclient management clear" almost reads as though ssh access to the remote public IP is also disabled. Confirm please?

This documentation line is part of what I'm talking about as being confusing: management access is granted to the inside. I access the remote 501 (with 6.3) via the inside IP address, and therefore, over a tunnel. Same thing for syslog, snmp, etc. But the line above talks about management via the outside interface, and earlier, about tunnels (which frequently appear to be documented as ending on the inside).

I am a technical guy, but not so deeply as to be security+ or anything like that. The whole IPsec thing drives me nuts, mostly as I haven't had to delve into it deeply and long enough to ingrain the concepts, and because there are so many new terms that are not intuitive.

Can someone explain this whole tunnel thing on a 501 - particularly in the sense of tunnel 'endings'?

I expect that because this isn't clear for me, I have problems with associated access lists on devices on either side of PIXies.

[Phil Williamson]

Is the "crypto" ACL my NAT0 ACL or my crypto map "match address" ACL?

HEAD-END-PIX - DHCP Server Here

access-list NoNAT permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.255.255.0

access-list NoNAT permit ip 10.1.1.0 255.255.255.0 10.1.3.0 255.255.255.0

access-list NoNAT permit ip 10.1.1.0 255.255.255.0 10.1.4.0 255.255.255.0

access-list Rmt-2 permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.255.255.0

access-list Rmt-3 permit ip 10.1.1.0 255.255.255.0 10.1.3.0 255.255.255.0

access-list Rmt-4 permit ip 10.1.1.0 255.255.255.0 10.1.4.0 255.255.255.0

nat (inside) 0 access-list NoNAT

nat (inside) 1 10.1.1.0 255.255.255.0 0 0

crypto map VPN-MAP 2 ipsec-isakmp

crypto map VPN-MAP 2 match address Rmt-2

crypto map VPN-MAP 2 set peer 12.12.12.2

crypto map VPN-MAP 2 set transform-set STRONG

crypto map VPN-MAP 3 ipsec-isakmp

crypto map VPN-MAP 3 match address Rmt-3

crypto map VPN-MAP 3 set peer 12.12.12.3

crypto map VPN-MAP 3 set transform-set STRONG

crypto map VPN-MAP 4 ipsec-isakmp

crypto map VPN-MAP 4 match address Rmt-4

crypto map VPN-MAP 4 set peer 12.12.12.4

crypto map VPN-MAP 4 set transform-set STRONG

Example Rmt-2 PIX config

access-list NoNAT permit ip 10.1.2.0 255.255.255.0 10.1.1.0 255.255.255.0

access-list Core-1 permit ip 10.1.2.0 255.255.255.0 10.1.1.0 255.255.255.0

nat (inside) 0 access-list NoNAT

nat (inside) 1 10.1.2.0 255.255.255.0 0 0

crypto map VPN-MAP 1 ipsec-isakmp

crypto map VPN-MAP 1 match address Core-1

crypto map VPN-MAP 1 set peer 12.12.12.1

crypto map VPN-MAP 1 set transform-set STRONG

You also mention in this thread having to open UDP/67 on the head-end pix to allow the DHCP requests - I thought they were coming in via the VPN tunnel?

Phil