Hi Aida,
thanks first of all for your answer.
I've fixed the problem, and will post about it in a moment, but first some
answers.
Now, the dhcp request is going to be sourced from the outside
interface which is not advertised on the nat 0 acl, so try
reconfiguring the NAT 0 acl on the Hub Pix for the traffic coming
from the pix outside ip address to the internal subnet for the dhcp
server.
Do you have any idea why this is? That is, why the DHCP-Packet is not sourced
from the inside address?
Incidentally, I got it working in a lab like this. Unfortunately it's not
feasible in real life, because there would be a routing conflict. The inside
PIX is not the default gw for anything - only specific (internal) subnets are
routed to it.
Finally, Im supposing you will dynamic ip address on the outside
interface of the client Pix (since ezvpn is being used) if that is
the case you will face another problem, the problem will be that we
don?t know the ip address from where the dhcp request is going to be
source from , so you will need to modify the acl every time the isp
changes ips, which is not good. Thinking on this, you may have the
following options:
This was the problem I stood before yesterday.
1- a workaround can be used, where if the ISP always assigns addresses
from the same subnet ranges, you can add that subnet range as a source
and the dhcp server as destination in the split-tunneling rule on the
central pix
This was my plan.
2- ask Roland to opening a PERs request to be able to make the source
of the packet
configurable, in this case the inside interface of the pix
3- the final solution is a kind of re-design, which is to assign ip
addresses from the ezvpn pix itself. This has it's
advantages/disadvateges:
Disadvantage: you can't centralise dhcp addresses and manage them via
one dhcp server. you have to configure this on each remote ezvpn pix.
Advantage: if the ipsec tunnel is down and can't establish for some
reason, the PCs will still be able to get an ip address from the ezvpn
pix and will be able at least to browse the internet.
Unfortunately the PIX can't do custom DHCP-Options. I had considered putting a
DHCP Server in the local net, but ended up solving the problem.
But actually, I guess that if you keep the split tunneling out of the
picture, everything should work.
Hope this helps!
Aida Lumbreras
----------------------------------------
<$Nombre> escribió el <$Fecha>:
Hi Cosmin,
Here are the relevant parts (things in caps are sanitized):
REMOTE SITE PIX
hostname REMOTE
access-list outside_access_in permit icmp any interface outside
echo-reply
access-list outside_access_in permit ip any any
access-list inside_access_out permit ip any any
logging on
logging buffered informational
ip address outside REMOTE_OUTSIDE 255.255.255.240
ip address inside REMOTE_INSIDE 255.255.255.0
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group outside_access_in in interface outside
access-group inside_access_out in interface inside
route outside 0.0.0.0 0.0.0.0 CORRECT_STANDARD_GW 1
management-access inside
dhcprelay server DHCP_IP outside
dhcprelay enable inside
vpnclient server GATEWAY_OUTSIDE
vpnclient mode network-extension-mode
vpnclient vpngroup GROUP password GROUP_PW
vpnclient username USER password USER_PW
vpnclient enable
CENTRAL PIX
hostname CENTRAL
access-list outside_access_in permit icmp any interface outside
echo-reply
access-list inside_access_out permit ip any any
access-list outside_access_in permit ip any any
access-list inside_outbound_nat0_acl permit ip any REMOTE_INSIDE
255.255.255.0
access-list outside_cryptomap_dyn_20 permit ip any REMOTE_INSIDE 0
255.255.255.0
logging on
logging buffered informational
ip address outside GATEWAY_OUTSIDE 255.255.255.240
ip address inside GATEWAY_INSIDE 255.255.255.0
ip local pool REMOTE_POOL 10.180.248.0-10.180.248.255
global (outside) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 CORRECT_STANDARD_GW 1
sysopt connection permit-ipsec
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map outside_dyn_map 20 match address
outside_cryptomap_dyn_20
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map client authentication LOCAL
crypto map outside_map interface outside
isakmp enable outside
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash md5
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup GROUP address-pool REMOTE_POOL
vpngroup GROUP dns-server DNS
vpngroup GROUP wins-server WINS
vpngroup GROUP default-domain DOMAIN.TLD
vpngroup GROUP idle-time 1800
vpngroup GROUP password GROUP_PW
username USER password USER_PW priv 3
Before anyone shoots off that there's no nat 0 rule on the remote
side,
remember that this rule comes automagically from the vpnclient, and
is
correct - I checked.
The any/any access-lists are, of course, just for testing. So they
will
obviously be changed as soon as the boat is afloat (these firewalls
and
the VLANs inbetween are actually all on my table at the moment being
tested.) I am also aware that I don't need the inside_access_in
access-lists - I just use them as an easy way to watch the hit counts
for packets being passed.
Thanks for any assistance,
Chris
-----Original Message-----
From: Stejerean, Cosmin [mailto:cosmin@cti.depaul.edu]
Sent: Thursday, March 16, 2006 11:35 PM
To: Meidinger Chris
Subject: RE: PIX dhcprelay via IPSec.
Sounds to me that you have a problem with routing. Can you do a
traceroute from a client to the DHCP server to make sure that
the packet
follows the correct route. Why would pinging from the remote
pix to the
DHCP server work over the inside interface? The inside interface
connects you to the client network not the VPN, right? Can
you post the
entire config file (after sanitizing any confidential information)?
Cosmin
-----Original Message-----
From: Meidinger Chris [mailto:chris.meidinger@badenIT.de]
Sent: Thursday, March 16, 2006 1:44 AM
To: Stejerean, Cosmin; firewalls@securityfocus.com
Subject: RE: PIX dhcprelay via IPSec.
Hi Cosmin,
I forgot to mention in my original post, that I can hping on
udp/67 in both directions as well.
I've also noticed, that on the remote firewall i can't ping
the DHCP-Server normally, but i can if I specify the inside
interface. That is, "ping x.x.x.x" doesn't work, but but
"ping inside x.x.x.x" does work.
Can anyone think of a reason for that?
I'd appreciate any more ideas, because I've got quite a bit
of pressure to get this running.
Thanks,
Chris
-----Original Message-----
From: Stejerean, Cosmin [mailto:cosmin@cti.depaul.edu]
Sent: Thursday, March 16, 2006 3:04 AM
To: Meidinger Chris; firewalls@securityfocus.com
Subject: RE: PIX dhcprelay via IPSec.
Do you have rules to allow traffic on UDP 67 on all the PIX
boxes? The
fact that you can ping the DHCP server means you can deliver
ICMP
packets but UDP packets on port 67 might be filtered
along the way.
Try to send a UDP packet on port 67 to the DHCP server
using nmap and
see if your sniffers pick it up. If it gets dropped you
should see
where it gets dropped. If this udp packet makes it
through then you
probably have some more serious issue with the remote pix.
Also make
sure the return packet can make it's way back to the remote
pix.
Regards,
Cosmin Stejerean
-----Original Message-----
From: Meidinger Chris [mailto:chris.meidinger@badenIT.de]
Sent: Wednesday, March 15, 2006 5:22 PM
To: firewalls@securityfocus.com
Subject: PIX dhcprelay via IPSec.
Hi List,
I have a question about relaying DHCP over VPN with PIX.
I have the following setup:
Client
|
|
|
Remote Site PIX running in network-extension mode
|V|
|P| Internet
|N|
Central PIX acting as concentrator
|
| Net 1
|
Inside Pix providing access control
|
| Net 2
|
DHCP Server x.x.x.x
The client needs to talk to the DHCP-Server in Net 2.
It can ping
the DHCP fine so routing and all is OK, but the relayed
Unicasts on
udp/67 seem to die inside the remote PIX. No log
messages, no debug
messages (at least in any debug mode I though to try) and
still no
packet.
I have the following config:
hostname(config)# show dhcprelay
dhcprelay server x.x.x.x outside
dhcprelay enable inside
I see statistics,
hostname(config)# show dhcprelay stat Packets Relayed
BOOTREQUEST 0
DHCPDISCOVER 48
DHCPREQUEST 0
DHCPDECLINE 0
DHCPRELEASE 0
DHCPINFORM 0
BOOTREPLY 0
DHCPOFFER 0
DHCPACK 0
DHCPNAK 0
but no packet in Net 1 and no packet in Net 2 (got inline
sniffers
in both trying to troubleshoot this)
Can anyone point me in the right direction what the problem
might be?
Thanks in advance,
Chris
