Posts: 478
Joined: 3.Jun.2003
From: Albuquerque NM USA
Status: offline
Hi Tom,
I tested it with the rules I posted on my site, and it still doesn't work. The VPN connection succeeds, but it seems that the ISA firewall is convinced that the VPN client's DHCP request is a spoofed packet and drops it. I'm going to disable IP spoof detection on the firewall and see if it works after I do that.
By the way, I just want to say that you are doing a great job in your writing and also answering questions in your forums here. Conversing with you is a real pleasure. Best wishes on the book!
I tested it with the rules I posted on my site, and it still doesn't work. The VPN connection succeeds, but it seems that the ISA firewall is convinced that the VPN client's DHCP request is a spoofed packet and drops it. I'm going to disable IP spoof detection on the firewall and see if it works after I do that.
By the way, I just want to say that you are doing a great job in your writing and also answering questions in your forums here. Conversing with you is a real pleasure. Best wishes on the book!
Bill
Hi Bill,
Thanks!
What I'm going to do tonight is try to figure out why its detected as a spoof. ISA sees a spoof when a packet reaches an interface which is not directly reachable by that interface.
So, questions I would ask is:
1. What network is the DHCP Inform packet coming from? The DHCP relay should be on the local host network, but the VPN client is on the VPN client's network. However, the source IP address, IIRC, is the VPN client's address, even though the relay is "routing" the connection.
2. What is the destination network interface detecting the spoof? I figure it must be the local host network, but maybe its the internal network?
It'll be interesting to see if this is figurable outable
Posts: 478
Joined: 3.Jun.2003
From: Albuquerque NM USA
Status: offline
quote:1. What network is the DHCP Inform packet coming from? The DHCP relay should be on the local host network, but the VPN client is on the VPN client's network. However, the source IP address, IIRC, is the VPN client's address, even though the relay is "routing" the connection.
2. What is the destination network interface detecting the spoof? I figure it must be the local host network, but maybe its the internal network?
Hi Tom,
In my test, the log tells me that the source network is VPN Clients and the destination network is Local Host.
Posts: 16
Joined: 7.Oct.2003
From: Torrance, CA
Status: offline
If you change things for ISA VPN that affect to RRAS, like the number of PPTP or L2TP connections, perform the following to force RRAS to find the changes. This also applies to changes in DCHP if your have configured RRAS for DHCP Relay.
1> Click Start, point to Programs, point to Administrative Tools and click on Routing and Remote Access. 2> In the Routing and Remote Access console, right click on the server name in the left pane of the console. Point to All Tasks and click on Restart.
This will cause the RRAS server to obtain IP addresses and refresh the DCHP leases.
Posts: 478
Joined: 3.Jun.2003
From: Albuquerque NM USA
Status: offline
Hi Andy,
The problem we are describing in this thread is as follows:
1. Run the DHCP service on the ISA/VPN server 2. Configure the DHCP Relay Agent on the ISA/VPN server to relay DHCP messages to itself 3. Remote VPN clients do not receive the DHCP options (LAN clients behind ISA work fine)
I messed with it for a couple of hours today, and I'm seeing the same thing. I think the problem is related to a bug in the "Internal" interface that RRAS uses and its interaction with a co-lo DHCP server/DHCP relay agent. I couldn't get it to work without the ISA firewall installed either.
If we had the option to bind the DHCP service to this "RRAS Internal" interface, it might work, but it isn't exposed in the DHCP UI -- maybe there's a Registry workaround?
Posts: 478
Joined: 3.Jun.2003
From: Albuquerque NM USA
Status: offline
Hi Tom,
Try the following commands at the command line:
code:
netsh routing ip relay show global netsh routing ip relay show ifbinding netsh routing ip relay show ifconfig netsh routing ip relay show ifstats netsh routing ip relay show interface
Here are my outputs:
From show global:
code:
DHCP Relay Global Configuration Information ------------------------------------------------------ Logging Level : Errors Only Max Receive Queue Size : 1048576 Server Count : 1
DHCP Server Addresses ------------------------------------------------------ 192.167.15.7
From show ifbinding:
code:
Error 57 retrieving information from the Routing and Remote Access service The parameter is incorrect.
From show ifconfig:
code:
DHCP Relay Agent Interface Config for : Internal -------------------------------------------------- State ENABLED Relay Mode ENABLED Max Hop Count 4 Minimum Seconds Since Boot 4
The parameter is incorrect.
From show ifstats:
code:
DHCP Relay Agent Interface Stats for : Internal -------------------------------------------------- State ENABLED Send Failures 0 Receive Failures 0 ARP Update Failures 0 Requests Received 0 Requests Discarded 0 Replies Received 0 Replies Discarded 0
From show interface:
code:
DHCP Relay Agent Configuration for "Internal" ------------------------------------------------------ State : Disabled and Unbound RelayMode : enable Max Hop Count : 4 Min seconds since reboot : 4
Even when I enter:
code:
netsh routing ip relay set interface Internal enable 4 4
The netsh routing ip relay show interface command still shows "Disabled and unbound."
I also find it odd that the show ifbinding displays error 57, which to Win32 means "A network adapter hardware error occurred." I don't know if this is significant or not (seeing as Internal is not a physical adapter).
I seem to recall hearing from someone last year that there was a bug either in RRAS that prevented this from working. Maybe its a feature, and not a bug?
Posts: 478
Joined: 3.Jun.2003
From: Albuquerque NM USA
Status: offline
Hi Tom,
Yes -- I hope we can get the DHCP issue resolved. That might turn into a problem in "appliance" scenarios. It'd be disappointing that you'd be able to do more with VPN on a PIX than an ISA Server appliance.
About the book: I'm sure you've got it covered! I do suggest separating the VPN chapter in half--one half covering remote client VPNs (including the CMAK), and the other covering site-to-site VPNs.
Regarding remote client VPNs, I'd suggest an explanation of the "Use default gateway on remote network" option, as a common question seems to be: "Why can't I [browse the web, access other local networks, etc.] when I connect to my VPN?"