VPN Question for Jeff Wiltshire (or any other firewall guru)
#1
Jeff,
I'm finally getting to grips with my VPN setup, but I've a couple of probs I can't get to the bottom of.
I tested my laptop from home this morning by plugging my cable modem straight into the NIC. I installed ZoneAlarm and setup the VPN client (NetScreen Remote 7). That worked great, but when I connect the same laptop to my home network it stops working.
The home network is a PC with two NIC's running ZoneAlarm. First NIC goes straight into the cable modem, the other to a switch for the other PC's and laptop. The PC also runs ICS and uses NAT witha 192.168.0.0 internal network address.
Is it the NAT that's stopping things? If I disable ZoneAlarm, it makes no difference
The second problem is trying to get to another network segment once I've connected to the VPN. Our office has another couple of routers to other remote offices. I need to be able to connect from home and effectively connect to any device on our internal network. It's fine from the office, but no joy via the VPN. Is this a VPN prob or some sort of routing issue between the remote laptop and the internal network?
Cheers,
Stefan
I'm finally getting to grips with my VPN setup, but I've a couple of probs I can't get to the bottom of.
I tested my laptop from home this morning by plugging my cable modem straight into the NIC. I installed ZoneAlarm and setup the VPN client (NetScreen Remote 7). That worked great, but when I connect the same laptop to my home network it stops working.
The home network is a PC with two NIC's running ZoneAlarm. First NIC goes straight into the cable modem, the other to a switch for the other PC's and laptop. The PC also runs ICS and uses NAT witha 192.168.0.0 internal network address.
Is it the NAT that's stopping things? If I disable ZoneAlarm, it makes no difference
The second problem is trying to get to another network segment once I've connected to the VPN. Our office has another couple of routers to other remote offices. I need to be able to connect from home and effectively connect to any device on our internal network. It's fine from the office, but no joy via the VPN. Is this a VPN prob or some sort of routing issue between the remote laptop and the internal network?
Cheers,
Stefan
#3
Effectively you need to either forward the necessary ports to your VPN machine (50, 500,) by default or add some form of Static NAT. The easiest way around this would be to use (as suggested) some form of Router (RRAS in Win2K) such as one of the cheaper Netgear products and do away with ICS.
Jeff
Jeff
#4
OK, that makes sense.
What about being able to ping remote networks? I'm back in the office testing a latop with a simple dial-up connection to Freeserve. I can ping the local LAN (direct connection with firewall/VPN machine), but can't get to the remote networks.
How does the remote machine appear to the internal network? does it have an IP address, or does it just look like the lan interface of the firewall/vpn machine?
So, say I'm sitting at my office pc and want to ping the remote laptop. How do I know what IP address it's using?
Stefan
What about being able to ping remote networks? I'm back in the office testing a latop with a simple dial-up connection to Freeserve. I can ping the local LAN (direct connection with firewall/VPN machine), but can't get to the remote networks.
How does the remote machine appear to the internal network? does it have an IP address, or does it just look like the lan interface of the firewall/vpn machine?
So, say I'm sitting at my office pc and want to ping the remote laptop. How do I know what IP address it's using?
Stefan
#5
To be able to access the remote networks you need to add those networks to your VPN SA at both ends. The Netscreen at your office will need to know how to get to the remote networks (via an internal router?). This should be easy to achieve with the Netscreen.
You'll not know what IP address a VPN client will come in on unless it has a fixed address, your SA at the Office end will have something like 0.0.0.0 - 255.255.255.254 as the acceptable client IP address. The only other alternative to this is to have a Netscreen box at your end of the circuit (5XP ?) and use DHCP via VPN for the clients within your home network. I'm not sure that Netscreen has that functionality but its something that SonicWALL can do so I'm guessing that Netscreen will have implemented it as well.
Jeff
You'll not know what IP address a VPN client will come in on unless it has a fixed address, your SA at the Office end will have something like 0.0.0.0 - 255.255.255.254 as the acceptable client IP address. The only other alternative to this is to have a Netscreen box at your end of the circuit (5XP ?) and use DHCP via VPN for the clients within your home network. I'm not sure that Netscreen has that functionality but its something that SonicWALL can do so I'm guessing that Netscreen will have implemented it as well.
Jeff
#6
Jeff,
VPN SA = Security Association ????
The VPN machine is a Linux box from Trustix, but they use the NetScreen Remote client only. From what I can tell the SonicWall client is the same.
The Trustix box allows "Virtual IP" to be defined for each user. You then set this IP address in the Security Policy of the NetScreen Remote PC. Is this the same thing you suggested?
Our network routes are already configured, so if a remote machine comes in with the same IP address and default gateway as one on the local LAN, it should all work.
What I can't figure out is if the remote machines must come in on another subnet or not?
Stefan
VPN SA = Security Association ????
The VPN machine is a Linux box from Trustix, but they use the NetScreen Remote client only. From what I can tell the SonicWall client is the same.
The Trustix box allows "Virtual IP" to be defined for each user. You then set this IP address in the Security Policy of the NetScreen Remote PC. Is this the same thing you suggested?
Our network routes are already configured, so if a remote machine comes in with the same IP address and default gateway as one on the local LAN, it should all work.
What I can't figure out is if the remote machines must come in on another subnet or not?
Stefan
#7
Stefan,
Havent worked with that kit but by the sounds of it to me you may have a routing problem.
If the remote client attaches with a similar IP address/mask of a local network, then you would have to configure your VPN device to provide Proxy ARP's for that device as devices on the same subnet will only ARP for that address. The VPN device would then need to provide the ARP address for the VPN client, then the traffic is routed at the VPN device and NATed and thus onto the client. The other way if Proxy ARP's are not possible then use static host routes. If it were me I would make the VPN clients get NATed behind a very specific range. That way on your internal network you will always recognise them.
In Checkpoint terms usually you can either :
1) Configure a NAT Pool for the incomming clients to get hidden behind. (Recomended path) - I have used this extensivly and usualy get a smallish subnet alocated by the network team (say a /24 block) that is routed at the VPN/Firewalls internal address (and propogated by any internal routers)
2) Source NAT all VPN traffic behind the Firewalls/VPN devices internal address - Checkpoint dont advocate doing this - but it works
PIX is very similar with a few gotchas
I'd agree with the others about scapping ICS though as I have found it a little ropey in the past. RRAS is a better solution, and a 'proper' router even better.
Sorry I cant offer more specific help, but i'm still building a test rig Linux/BSD based VPN device for testing.
Ids
Havent worked with that kit but by the sounds of it to me you may have a routing problem.
If the remote client attaches with a similar IP address/mask of a local network, then you would have to configure your VPN device to provide Proxy ARP's for that device as devices on the same subnet will only ARP for that address. The VPN device would then need to provide the ARP address for the VPN client, then the traffic is routed at the VPN device and NATed and thus onto the client. The other way if Proxy ARP's are not possible then use static host routes. If it were me I would make the VPN clients get NATed behind a very specific range. That way on your internal network you will always recognise them.
In Checkpoint terms usually you can either :
1) Configure a NAT Pool for the incomming clients to get hidden behind. (Recomended path) - I have used this extensivly and usualy get a smallish subnet alocated by the network team (say a /24 block) that is routed at the VPN/Firewalls internal address (and propogated by any internal routers)
2) Source NAT all VPN traffic behind the Firewalls/VPN devices internal address - Checkpoint dont advocate doing this - but it works
PIX is very similar with a few gotchas
I'd agree with the others about scapping ICS though as I have found it a little ropey in the past. RRAS is a better solution, and a 'proper' router even better.
Sorry I cant offer more specific help, but i'm still building a test rig Linux/BSD based VPN device for testing.
Ids
Trending Topics
#8
Stefan
You'll need to add a Security Association (SA !) for each of the networks you want to get too.....
If as you say the Netscreen client is the same as the SonicWALL client (SafeNet) then you should have a line for each of your internal networks. Something like
My Connections
10.0.0.0 Internal A
172.30.0.0 Internal B
192.168.0.0 Internal C
All of your networks need to be defined in the client or any IP traffic for those destinations wouldn't be sent down the tunnel.
You will also need to ensure that the VPN SA on the Tunnel Terminator has these networks in its SA for your client.
Cheers
Jeff
You'll need to add a Security Association (SA !) for each of the networks you want to get too.....
If as you say the Netscreen client is the same as the SonicWALL client (SafeNet) then you should have a line for each of your internal networks. Something like
My Connections
10.0.0.0 Internal A
172.30.0.0 Internal B
192.168.0.0 Internal C
All of your networks need to be defined in the client or any IP traffic for those destinations wouldn't be sent down the tunnel.
You will also need to ensure that the VPN SA on the Tunnel Terminator has these networks in its SA for your client.
Cheers
Jeff
#10
Hi Jeff,
In a word, No. I've been off all last week with the flu so didn't spend any more time on it.
I'll try and post some more info later today to explain what I'm trying to do.
Stefan
In a word, No. I've been off all last week with the flu so didn't spend any more time on it.
I'll try and post some more info later today to explain what I'm trying to do.
Stefan
Thread
Thread Starter
Forum
Replies
Last Post
Brzoza
Engine Management and ECU Remapping
1
02 October 2015 06:26 PM