Flat network with a tunnel in the middle?
March 19, 2012 2:58 PM Subscribe
I need to set up a VPN between two Juniper Netscreens... with some strange requirements. Is it possible?
I work for a company that often requires non standard solutions to...well...non standard problems. This is one of those situations. I am stumped, and it's been blowing my head up a bit, so I'm hoping there is a resident VPN expert somewhere in the hive mind.
On one side of the VPN (side 1) we have a device that will ONLY route to the one subnet it knows about. Let's say that's 10.1.1.0/24. That device is a DHCP server. It is not possible to set up routes to anywhere else, from what I am being told by the people in charge at that company. Yes, I have pushed. No, this doesn't make sense to me, but I am told it cannot be changed.
On the edge of that 10.1.1.1 network lives a Juniper NS5GT with one interface in the 10.1.1.X network and the other in a 10.1.2.X network, natted out to a public IP on their gateway to the internet.
On the other side of the VPN (side 2), indeed, in another country, is a network we have full control of, and on the edge is a Juniper Netscreen. One side has a public IP, the other side has a 172.16.1.X IP address (although this is of our choosing, so it can be changed). We also have a wireless access point and another device connected to the 172.16.1.X network. We need all devices on that network of the Juniper Netscreen to get DHCP addresses assigned to it by the DHCP server at side 1.
The tunnel has been set up as a route based VPN. Traffic passes fine from side 2 to the internal IP of the Juniper at side 1. The issue is that from side 2 devices we cannot even PING 10.1.1.1, much less get an IP assigned by it.
DHCP relay has been set up on the Juniper at side 2, with the 10.1.1.1 address as its server. But no DHCP traffic is passing through, and indeed, once the traffic hits the Juniper at side 1, it appears to go out to 10.1.1.1 but never returns.
Some thoughts I've had but haven't fully fleshed out - Can we set up NAT to somehow NAT all traffic coming in from side 1 to a 10.1.1.X IP? Will that even work? How do we make the Netscreens basically transparent? My boss also brought up the possibility of policy based VPN instead of route based, but I believe with a policy based we will still need routing. Even if we get all the devices on one side of the VPN to get IPs from the DHCP server on the other end - how will it know where to send traffic to which 10.1.1.X IPs? They basically want this to be a flat network design with this VPN hidden in the middle of it. Should I be sourcing the tunnel from the 10.1.1.X interface on the Netscreen at side 1?
Do you know of any way to make this work?
Yes, I am routergirl, but VPNs on the Junipers are a new thing for me. This, like I said, is blowing up my head. Please help. Even if your solution includes sacrificing a chicken, if it makes this work, I am all ears.
I work for a company that often requires non standard solutions to...well...non standard problems. This is one of those situations. I am stumped, and it's been blowing my head up a bit, so I'm hoping there is a resident VPN expert somewhere in the hive mind.
On one side of the VPN (side 1) we have a device that will ONLY route to the one subnet it knows about. Let's say that's 10.1.1.0/24. That device is a DHCP server. It is not possible to set up routes to anywhere else, from what I am being told by the people in charge at that company. Yes, I have pushed. No, this doesn't make sense to me, but I am told it cannot be changed.
On the edge of that 10.1.1.1 network lives a Juniper NS5GT with one interface in the 10.1.1.X network and the other in a 10.1.2.X network, natted out to a public IP on their gateway to the internet.
On the other side of the VPN (side 2), indeed, in another country, is a network we have full control of, and on the edge is a Juniper Netscreen. One side has a public IP, the other side has a 172.16.1.X IP address (although this is of our choosing, so it can be changed). We also have a wireless access point and another device connected to the 172.16.1.X network. We need all devices on that network of the Juniper Netscreen to get DHCP addresses assigned to it by the DHCP server at side 1.
The tunnel has been set up as a route based VPN. Traffic passes fine from side 2 to the internal IP of the Juniper at side 1. The issue is that from side 2 devices we cannot even PING 10.1.1.1, much less get an IP assigned by it.
DHCP relay has been set up on the Juniper at side 2, with the 10.1.1.1 address as its server. But no DHCP traffic is passing through, and indeed, once the traffic hits the Juniper at side 1, it appears to go out to 10.1.1.1 but never returns.
Some thoughts I've had but haven't fully fleshed out - Can we set up NAT to somehow NAT all traffic coming in from side 1 to a 10.1.1.X IP? Will that even work? How do we make the Netscreens basically transparent? My boss also brought up the possibility of policy based VPN instead of route based, but I believe with a policy based we will still need routing. Even if we get all the devices on one side of the VPN to get IPs from the DHCP server on the other end - how will it know where to send traffic to which 10.1.1.X IPs? They basically want this to be a flat network design with this VPN hidden in the middle of it. Should I be sourcing the tunnel from the 10.1.1.X interface on the Netscreen at side 1?
Do you know of any way to make this work?
Yes, I am routergirl, but VPNs on the Junipers are a new thing for me. This, like I said, is blowing up my head. Please help. Even if your solution includes sacrificing a chicken, if it makes this work, I am all ears.
Response by poster: Unfortunately we do not have access to the DHCP server. It is under the control of another company, so while we can relay requests for such information from them, we've got to work blind as much as possible.
The transparency thing is the thing I am most curious about. You would think it would be possible, I've just never set such a thing up.
posted by routergirl at 3:16 PM on March 19, 2012
The transparency thing is the thing I am most curious about. You would think it would be possible, I've just never set such a thing up.
posted by routergirl at 3:16 PM on March 19, 2012
Best answer: Oh, that's too bad.
Just so I'm seeing this right, you've got this:
clients > JuniperA > vpn > JuniperB > DHCP server
DHCPrelay is on JuniperA.
DHCP server only has a route to only the same net that JuniperB is attached to?
Is the DHCP relay on JuniperA relaying direct to the DHCP server? What is the source address on those relayed DHCP req packets, after they go through the relay and through the VPN? (run a capture in verbose on the interface of JuniperB that connects to DHCPserver's net, and look at the headers of the dhcp request packets, you will see the relay server's address in it, which is where the dhcpserver will reply to).
I am guessing that the DHCPserver does see the packets, but the relay server's address is not one that it has a route to.
posted by Threeway Handshake at 3:19 PM on March 19, 2012
Just so I'm seeing this right, you've got this:
clients > JuniperA > vpn > JuniperB > DHCP server
DHCPrelay is on JuniperA.
DHCP server only has a route to only the same net that JuniperB is attached to?
Is the DHCP relay on JuniperA relaying direct to the DHCP server? What is the source address on those relayed DHCP req packets, after they go through the relay and through the VPN? (run a capture in verbose on the interface of JuniperB that connects to DHCPserver's net, and look at the headers of the dhcp request packets, you will see the relay server's address in it, which is where the dhcpserver will reply to).
I am guessing that the DHCPserver does see the packets, but the relay server's address is not one that it has a route to.
posted by Threeway Handshake at 3:19 PM on March 19, 2012
Best answer: And BTW, what you've got set up seems about right for this purpose. Running policy VPN and all that still relies on routes, and you'll end up with the same issue. You also can't NAT DHCP since there is no addresses in the header to rewrite.
posted by Threeway Handshake at 3:20 PM on March 19, 2012
posted by Threeway Handshake at 3:20 PM on March 19, 2012
It took me about three and a half reads before I could make sense of this. Does this look right?
posted by rhizome at 3:22 PM on March 19, 2012
DHCP---NetA1-\
JunA-------JunB-NetB
NetA2-/
NetA1: 10.1.1.x
NetA2: 10.1.2.x
NetB: 172.x.y.z
Side 1: NetAn
Side 2: NetB
posted by rhizome at 3:22 PM on March 19, 2012
Screenshot your visio diagram of all this and obfuscate what you need to. ;)
posted by Threeway Handshake at 3:23 PM on March 19, 2012
posted by Threeway Handshake at 3:23 PM on March 19, 2012
Response by poster: Yeah, I should have stuck a diagram up on Flickr or something. I will when I get in tomorrow. But Rhizome has got it.
The relay is set up on JuniperA, on the interface of 172.16.1.X, which is the "local side" of the VPN. I utilized Juniper tech support for the DHCP relay aspect, since I've never done the DHCP relay over VPN. They have looked at both ends and confirmed the config is solid, and like I said, I can ping the inside IP of JuniperB from JuniperA, so I know the tunnel is up.
My initial response to all this was, "Can't we just configure our end to be 10.1.1.X and make it look like they've received DHCP IPs?" Then it was, "Can't we just NAT them to look like 10.1.1.X IPs?" Etc.
We do have a support contract with Juniper, but they're not great at helping come up with solutions - more for helping make sure solutions are implemented correctly.
posted by routergirl at 3:46 PM on March 19, 2012
The relay is set up on JuniperA, on the interface of 172.16.1.X, which is the "local side" of the VPN. I utilized Juniper tech support for the DHCP relay aspect, since I've never done the DHCP relay over VPN. They have looked at both ends and confirmed the config is solid, and like I said, I can ping the inside IP of JuniperB from JuniperA, so I know the tunnel is up.
My initial response to all this was, "Can't we just configure our end to be 10.1.1.X and make it look like they've received DHCP IPs?" Then it was, "Can't we just NAT them to look like 10.1.1.X IPs?" Etc.
We do have a support contract with Juniper, but they're not great at helping come up with solutions - more for helping make sure solutions are implemented correctly.
posted by routergirl at 3:46 PM on March 19, 2012
Best answer: I'll check this again tomorrow.
If it ends up being that the DHCP server doesn't respond to the relay because the src of the relayed packets is in a net it has no route to, then (assuming that the DHCP relay packets get turned into regular unicast UDP with a source and dest address - I don't remember and don't have a relay to observe, but I think this is the case), you'd set up a xlate on those DHCPrelay packets on the Juniper next to the DHCPserver translating them to have a source address that the DHCPserver can talk back to.
posted by Threeway Handshake at 4:07 PM on March 19, 2012
If it ends up being that the DHCP server doesn't respond to the relay because the src of the relayed packets is in a net it has no route to, then (assuming that the DHCP relay packets get turned into regular unicast UDP with a source and dest address - I don't remember and don't have a relay to observe, but I think this is the case), you'd set up a xlate on those DHCPrelay packets on the Juniper next to the DHCPserver translating them to have a source address that the DHCPserver can talk back to.
posted by Threeway Handshake at 4:07 PM on March 19, 2012
Let's forget everything public for now. This needs to be solved INSIDE the VPN tunnel.
The DHCP request comes from a client on the other end of the VPN tunnel, crosses the VPN tunnel then hits the Peer-interface, 10.1.1.254 (guessing)
So you have an inside interface for the 10.1.1.x/24 network on the peer-vpn link, and you need to NAT.
I would create a new virtual interface for a brand new subnet on the peer-VPN device, say, 192.168.10.0/24. That network would need to be advertised across your VPN tunnel to the side you control.
You need to set up a static NAT on that 192.168.10.0/24 network, say take 192.168.10.10 and Static NAT that to 10.1.1.1 (DHCP Server IP).
On your end you'll need to set up DHCP Helper addresses/Relays on your equipment that say "DHCP is at IP Address 192.168.10.10!"
The traffic will route across the VPN, hit the static NAT, which will then get routed into your non-routable network.
The return DHCP response will then return the ip address of 192.168.10.10, and since that is a NAT it will get translated back to a routable source (which is the IP address of your DHCP Helper/Relay). That will come across the VPN tunnel, to your relay and back to your client.
You need to be looking at a combo of DHCP Relay and NAT to solve this problem.
posted by roboton666 at 7:02 PM on March 19, 2012
The DHCP request comes from a client on the other end of the VPN tunnel, crosses the VPN tunnel then hits the Peer-interface, 10.1.1.254 (guessing)
So you have an inside interface for the 10.1.1.x/24 network on the peer-vpn link, and you need to NAT.
I would create a new virtual interface for a brand new subnet on the peer-VPN device, say, 192.168.10.0/24. That network would need to be advertised across your VPN tunnel to the side you control.
You need to set up a static NAT on that 192.168.10.0/24 network, say take 192.168.10.10 and Static NAT that to 10.1.1.1 (DHCP Server IP).
On your end you'll need to set up DHCP Helper addresses/Relays on your equipment that say "DHCP is at IP Address 192.168.10.10!"
The traffic will route across the VPN, hit the static NAT, which will then get routed into your non-routable network.
The return DHCP response will then return the ip address of 192.168.10.10, and since that is a NAT it will get translated back to a routable source (which is the IP address of your DHCP Helper/Relay). That will come across the VPN tunnel, to your relay and back to your client.
You need to be looking at a combo of DHCP Relay and NAT to solve this problem.
posted by roboton666 at 7:02 PM on March 19, 2012
"return TO the ip address of 192.168.10.10"
posted by roboton666 at 7:26 PM on March 19, 2012
posted by roboton666 at 7:26 PM on March 19, 2012
Now I'm thinking about it some more and realizing they won't let traffic from the 10 network to anything.
That's kind of a sticky sitch there. I'll need to ponder that...
posted by roboton666 at 7:31 PM on March 19, 2012
That's kind of a sticky sitch there. I'll need to ponder that...
posted by roboton666 at 7:31 PM on March 19, 2012
Best answer: On one side of the VPN (side 1) we have a device that will ONLY route to the one subnet it knows about. Let's say that's 10.1.1.0/24. That device is a DHCP server. ... We also have a wireless access point and another device connected to the 172.16.1.X network. We need all devices on that network of the Juniper Netscreen to get DHCP addresses assigned to it by the DHCP server at side 1.
If that DHCP server is tied to 10.1.1.0/24, how is it ever going to hand out addresses in 172.16.1.X?
Sounds to me like what's really needed is a VPN with 10.1.1.0/24 appearing on both sides. If a layer 2 VPN is out of the question, could you perhaps do something clever with 10.1.1.0/25 and 10.1.1.128/25?
posted by flabdablet at 10:08 PM on March 19, 2012
If that DHCP server is tied to 10.1.1.0/24, how is it ever going to hand out addresses in 172.16.1.X?
Sounds to me like what's really needed is a VPN with 10.1.1.0/24 appearing on both sides. If a layer 2 VPN is out of the question, could you perhaps do something clever with 10.1.1.0/25 and 10.1.1.128/25?
posted by flabdablet at 10:08 PM on March 19, 2012
Response by poster: See, it's a shame I can't seem to find a way to create an L2TP tunnel between two Netscreens. While we'll have a couple of devices on side 2, neither is capable of establishing a tunnel out. I wonder if it would be worth just setting up a computer whose only role is to sit there and establish a VPN for the rest of the network.
posted by routergirl at 3:13 AM on March 20, 2012
posted by routergirl at 3:13 AM on March 20, 2012
Are you able to send the other company something to plug into their LAN? A couple of SheevaPlugs talking L2TP/IPSEC between themselves could work.
posted by flabdablet at 4:27 AM on March 20, 2012
posted by flabdablet at 4:27 AM on March 20, 2012
Best answer: If that DHCP server is tied to 10.1.1.0/24, how is it ever going to hand out addresses in 172.16.1.X?
flabdablet hits the point that was bothering me when I first read this last night. The way that DHCP relay works is that the server uses the IP address of the agent for two things: to determine the subnet that it should allocate an address from, and to know where to send the response. If you NAT the DHCP packet to a 10.1.1.x source address (so that the server can send a response back to the relay agent), then the server will only ever see requests for DHCP addresses on 10.1.1.0/24. And since that subnet is local to the DHCP server anyway, I fully expect its tiny head to explode when it tries to answer a relayed request for a local subnet.
I don't think there is a way to make this work without at least giving the DHCP server a default route pointed to JuniperA.
posted by McCoy Pauley at 4:36 AM on March 20, 2012
flabdablet hits the point that was bothering me when I first read this last night. The way that DHCP relay works is that the server uses the IP address of the agent for two things: to determine the subnet that it should allocate an address from, and to know where to send the response. If you NAT the DHCP packet to a 10.1.1.x source address (so that the server can send a response back to the relay agent), then the server will only ever see requests for DHCP addresses on 10.1.1.0/24. And since that subnet is local to the DHCP server anyway, I fully expect its tiny head to explode when it tries to answer a relayed request for a local subnet.
I don't think there is a way to make this work without at least giving the DHCP server a default route pointed to JuniperA.
posted by McCoy Pauley at 4:36 AM on March 20, 2012
Or something from Microtik could end up similarly minimal and unobtrusive and might be easier to set up.
posted by flabdablet at 4:38 AM on March 20, 2012
posted by flabdablet at 4:38 AM on March 20, 2012
Response by poster: The goal originally was to make it seem as though all things on side 2 were physically located where side 1 is - however the routing limitations on the DHCP server were only just revealed to me, which of course totally messed everything up. How do I make two broadcast domains look like one?
posted by routergirl at 5:00 AM on March 20, 2012
posted by routergirl at 5:00 AM on March 20, 2012
If that DHCP server is tied to 10.1.1.0/24, how is it ever going to hand out addresses in 172.16.1.X?
Because of DHCP relays. There's a relay on one side. A DHCP relay sends requests on behalf of clients to a real DHCP server in another network.
I fully expect its tiny head to explode when it tries to answer a relayed request for a local subnet.
Having things like this is pretty standard stuff. Every large network relies on DHCP relays. The DHCP server can assign DHCP addresses to anything it wants. The routing part is wholly separate from the DHCP daemon. The only important part of it is that the host OS of the DHCP server can reach the address that the DHCPrelay is sending from on behalf of the clients.
The goal originally was to make it seem as though all things on side 2 were physically located where side 1 is
To what goal though? Can you just run a DHCP server locally on both sides and then do a hidenat or a double-nat?
posted by Threeway Handshake at 6:38 AM on March 20, 2012
Because of DHCP relays. There's a relay on one side. A DHCP relay sends requests on behalf of clients to a real DHCP server in another network.
I fully expect its tiny head to explode when it tries to answer a relayed request for a local subnet.
Having things like this is pretty standard stuff. Every large network relies on DHCP relays. The DHCP server can assign DHCP addresses to anything it wants. The routing part is wholly separate from the DHCP daemon. The only important part of it is that the host OS of the DHCP server can reach the address that the DHCPrelay is sending from on behalf of the clients.
The goal originally was to make it seem as though all things on side 2 were physically located where side 1 is
To what goal though? Can you just run a DHCP server locally on both sides and then do a hidenat or a double-nat?
posted by Threeway Handshake at 6:38 AM on March 20, 2012
Response by poster: After going to my boss (and the people in charge of this project, and the tech at the company on the other side of the VPN), and explaining I don't know how this will work without a route on the DHCP server, they found a way to do what they previously said was impossible, and set a route.
Thank you all for your help this far - I was worried I was getting tunnel vision with this, and not seeing some obvious solution right in front of me. It sounds like I should have stuck with my gut and pushed the route harder from the beginning.
DHCP is still not relaying as it should, but I can see all of the packets being accepted on the firewalls, at least, now, and I'm troubleshooting by removing some devices from the picture on side 2 and having someone connect directly to the firewall to test the DHCP from there. We have a wireless access point there that is supposed to relay the DHCP to all connected devices as well, but I'm suspicious it's not, and that our new obstacle is getting it to run through that. Of course it is taking time - I'm on the east coast in Canada, and the VPN is going from Finland to France, so any on site tests are usually done while I'm sleeping, and I get to wake up to the results.
posted by routergirl at 7:42 AM on March 21, 2012
Thank you all for your help this far - I was worried I was getting tunnel vision with this, and not seeing some obvious solution right in front of me. It sounds like I should have stuck with my gut and pushed the route harder from the beginning.
DHCP is still not relaying as it should, but I can see all of the packets being accepted on the firewalls, at least, now, and I'm troubleshooting by removing some devices from the picture on side 2 and having someone connect directly to the firewall to test the DHCP from there. We have a wireless access point there that is supposed to relay the DHCP to all connected devices as well, but I'm suspicious it's not, and that our new obstacle is getting it to run through that. Of course it is taking time - I'm on the east coast in Canada, and the VPN is going from Finland to France, so any on site tests are usually done while I'm sleeping, and I get to wake up to the results.
posted by routergirl at 7:42 AM on March 21, 2012
Having things like this is pretty standard stuff. Every large network relies on DHCP relays. The DHCP server can assign DHCP addresses to anything it wants. The routing part is wholly separate from the DHCP daemon. The only important part of it is that the host OS of the DHCP server can reach the address that the DHCPrelay is sending from on behalf of the clients.
Threeway Handshake, that's the problem, though. In the situation we're talking about, the server doesn't have a route to the sending address of the relay agent (at least until the OP got one added). So you've got a choice of two untenable situations:
1) The DHCP request from the relay agent gets NAT'd, and the server sees a request coming from 10.1.1.0/24. Assuming it doesn't have problems because it sees a unicast request coming from its local subnet (where it should be seeing broadcast requests), then it returns a DHCP offer for an address in 10.1.1.0/24. That packet should get NAT'd back to the relay agent in 172.16.1.x, but it contains an offer for 10.1.1.x, which does the client no good at all.
2) The DHCP request from the relay agent does not get NAT'd, and arrives with a source IP of 172.16.1.x. The server can reply with a DHCP offer in the 172.16.1.x subnet, but it's got no way to route that packet back to the relay agent.
routergirl, are you getting actual packet captures off the Netscreens with the snoop command? If I were troubleshooting this, my next step would be to use snoop to do a detailed capture of the DHCP traffic and feed it into Wireshark (which can read snoop output from the Netscreens). Look at what's actually in the DHCPDISCOVER packet coming from the client so you know if it's going to make sense to the DHCP server.
posted by McCoy Pauley at 7:30 PM on March 21, 2012
Threeway Handshake, that's the problem, though. In the situation we're talking about, the server doesn't have a route to the sending address of the relay agent (at least until the OP got one added). So you've got a choice of two untenable situations:
1) The DHCP request from the relay agent gets NAT'd, and the server sees a request coming from 10.1.1.0/24. Assuming it doesn't have problems because it sees a unicast request coming from its local subnet (where it should be seeing broadcast requests), then it returns a DHCP offer for an address in 10.1.1.0/24. That packet should get NAT'd back to the relay agent in 172.16.1.x, but it contains an offer for 10.1.1.x, which does the client no good at all.
2) The DHCP request from the relay agent does not get NAT'd, and arrives with a source IP of 172.16.1.x. The server can reply with a DHCP offer in the 172.16.1.x subnet, but it's got no way to route that packet back to the relay agent.
routergirl, are you getting actual packet captures off the Netscreens with the snoop command? If I were troubleshooting this, my next step would be to use snoop to do a detailed capture of the DHCP traffic and feed it into Wireshark (which can read snoop output from the Netscreens). Look at what's actually in the DHCPDISCOVER packet coming from the client so you know if it's going to make sense to the DHCP server.
posted by McCoy Pauley at 7:30 PM on March 21, 2012
The DHCP request from the relay agent gets NAT'd, and the server sees a request coming from 10.1.1.0/24.
But the unicast packet does not matter. What matters is the GIADDR in the dhcpdiscover packet, which will be the correct origin. The NAT would not overwrite this part of it, it only will overwrite the src in the header of the unicast packet.
posted by Threeway Handshake at 7:54 AM on March 22, 2012
But the unicast packet does not matter. What matters is the GIADDR in the dhcpdiscover packet, which will be the correct origin. The NAT would not overwrite this part of it, it only will overwrite the src in the header of the unicast packet.
posted by Threeway Handshake at 7:54 AM on March 22, 2012
...which is case 2 above. The server still uses the GIADDR as the destination for the unicast reply, which it can't route.
posted by McCoy Pauley at 12:54 AM on March 23, 2012
posted by McCoy Pauley at 12:54 AM on March 23, 2012
And the DHCP server daemon is unaware of a host OS's route, so it doesn't matter.
posted by Threeway Handshake at 8:35 AM on March 23, 2012
posted by Threeway Handshake at 8:35 AM on March 23, 2012
The daemon will happily generate the response packet, but it then needs to hand it off to the host OS' IP stack for delivery, which will drop it instead of putting it on the wire, because it's got no route for the destination. The daemon's happy, but the client's kind of hosed.
posted by McCoy Pauley at 4:39 PM on March 23, 2012
posted by McCoy Pauley at 4:39 PM on March 23, 2012
The daemon will happily generate the response packet, but it then needs to hand it off to the host OS' IP stack for delivery, which will drop it instead of putting it on the wire, because it's got no route for the destination. The daemon's happy, but the client's kind of hosed.
If the unicast packet was being natted so as to have a (udp header) source of the dhcp server's routable network, then it would be just fine.
posted by Threeway Handshake at 10:36 AM on March 25, 2012
If the unicast packet was being natted so as to have a (udp header) source of the dhcp server's routable network, then it would be just fine.
posted by Threeway Handshake at 10:36 AM on March 25, 2012
I think that's where the problem is (that I see) -- as far as I can tell, the destination address for the DHCP response from the server is being generated from the GIADDR in the original request, not from the source IP on the request packet. So even if the request comes in with a NAT'd source address of 10.1.1.x, but the GIADDR is 172.16.1.x, then the server will put 172.16.1.x as the destination on the response packet, and that's where the routing breaks down.
This may depend on the implementation in the particular DHCP server software they're using, but as I read RFC2131, that's the proper behavior, which will cause problems in this case. From RFC 2131, Section 4.1:
If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'.
Meanwhile, I'm hoping the OP has had some luck solving her problem -- any news, routergirl?
posted by McCoy Pauley at 12:25 PM on March 26, 2012
This may depend on the implementation in the particular DHCP server software they're using, but as I read RFC2131, that's the proper behavior, which will cause problems in this case. From RFC 2131, Section 4.1:
If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'.
Meanwhile, I'm hoping the OP has had some luck solving her problem -- any news, routergirl?
posted by McCoy Pauley at 12:25 PM on March 26, 2012
Response by poster: Sorry, things have been hectic here.
We ended up doing what I was pushing for from the beginning- on the local side we set up the Netscreen to hand out IPs in our 172.16.1.X range. Then we got them to do what they claimed was "impossible" on the other side (getting a higher level tech always helps!) and set up a route from the 10.1.1.X network to our network on the other side of the tunnel.
So - basic tunnel, really. The things complicating this were that on the remote side the DHCP server was a Livebox, which is a device I'm not even remotely familiar with, so I was at the mercy of the people responsible for it. On our side we have a set top cable box, which they said needed to get "configurations" from the Livebox. Turns out all it needed was IP, Mask, GW and DNS, which our Netscreen was perfectly happy to provide. Once the route was in place, it all worked beautifully.
So the lesson here for me is that if they are trying to insist you do something that appears impossible, sometimes you have to just put your foot down and say no.
Handing out DHCP addresses in a 172.16.1.x network from a 10.1.1.x network? How could that even work? I mean, say the box got a 10.1.1.X IP. But then it would have to traverse the 172.16.1.x network to get BACK to 10.1.1.X. Then how would routing work, if both sides think they're the same network? Also - I dug deeper into the Juniper DHCP relay examples I could find, and in every case they were relaying IPs in a subnet that matched the other side of the VPN. So we could use a DHCP server at remote side, IF it handed out 172.16.1.X IPs. That was when I started pushing harder for the route they said wasn't possible.
The turning point was when the guys at our office set up a call to get a status, and the tech we'd been working with on the remote side was out of town, so we got a different one, who happened to be higher. I said, "Look, can you just go over why a DHCP server on our side wouldn't work?" Although the other tech said, "It HAS to be our DHCP server," this guy said, "We might as well try it." We had it all working an hour later.
You guys are awesome, and went above and beyond with the suggestions, thoughts, and answers. Thanks to all of you for helping me see this more clearly.
posted by routergirl at 7:48 PM on March 28, 2012
We ended up doing what I was pushing for from the beginning- on the local side we set up the Netscreen to hand out IPs in our 172.16.1.X range. Then we got them to do what they claimed was "impossible" on the other side (getting a higher level tech always helps!) and set up a route from the 10.1.1.X network to our network on the other side of the tunnel.
So - basic tunnel, really. The things complicating this were that on the remote side the DHCP server was a Livebox, which is a device I'm not even remotely familiar with, so I was at the mercy of the people responsible for it. On our side we have a set top cable box, which they said needed to get "configurations" from the Livebox. Turns out all it needed was IP, Mask, GW and DNS, which our Netscreen was perfectly happy to provide. Once the route was in place, it all worked beautifully.
So the lesson here for me is that if they are trying to insist you do something that appears impossible, sometimes you have to just put your foot down and say no.
Handing out DHCP addresses in a 172.16.1.x network from a 10.1.1.x network? How could that even work? I mean, say the box got a 10.1.1.X IP. But then it would have to traverse the 172.16.1.x network to get BACK to 10.1.1.X. Then how would routing work, if both sides think they're the same network? Also - I dug deeper into the Juniper DHCP relay examples I could find, and in every case they were relaying IPs in a subnet that matched the other side of the VPN. So we could use a DHCP server at remote side, IF it handed out 172.16.1.X IPs. That was when I started pushing harder for the route they said wasn't possible.
The turning point was when the guys at our office set up a call to get a status, and the tech we'd been working with on the remote side was out of town, so we got a different one, who happened to be higher. I said, "Look, can you just go over why a DHCP server on our side wouldn't work?" Although the other tech said, "It HAS to be our DHCP server," this guy said, "We might as well try it." We had it all working an hour later.
You guys are awesome, and went above and beyond with the suggestions, thoughts, and answers. Thanks to all of you for helping me see this more clearly.
posted by routergirl at 7:48 PM on March 28, 2012
Well done you.
Overcoming PEBKAC issues can be really hard, especially remote ones.
posted by flabdablet at 9:04 PM on March 28, 2012
Overcoming PEBKAC issues can be really hard, especially remote ones.
posted by flabdablet at 9:04 PM on March 28, 2012
Congratulations! Glad it hear it got sorted.
posted by McCoy Pauley at 7:54 AM on March 29, 2012
posted by McCoy Pauley at 7:54 AM on March 29, 2012
This thread is closed to new comments.
Run a packet cap on it if you can and look at where it's replies are going.
posted by Threeway Handshake at 3:08 PM on March 19, 2012