Dial-Up to Site with Multiple Sub-Nets?
workers last edited by
I have an older, flat, network behind an older firewall. The goal is to re-arrange the flat network into sub-nets with Dial-Up VPN access. The sub-nets are:
- public network with web server, mail, etc.
Software developers and IT should be able to use a VPN client to connect and look like just a node on the different sub-nets.
The current network has a large number of machines, so a transparent bridge is needed to first move the site behind the new firewall. To provide a Layer 3 VPN network port, it seems that an SSG port is used for that. So, a proposed SSG5 port layout would look like this:
Port # Comment
0 WAN (v1-untrust)
1 DMZ (v1-DMZ) - plugged into old site network
2 High Availability
3 VPN gateway - plugged into old site network
4 Admin sub-net, 10.25.1.XXX
5 Engineering sub-net, 10.50.1.XXX
6 Users sub-net, 10.75.1.XXX
So far, I have successfully setup an L2TP-IPSEC in transport mode with NAT-T and certificates, have connected to the VPN, and can see the packets making it through the tunnel but then dropped because there is no route from Port 3 to the sub-nets. I have an ippool, 192.168.255.1 - 192.168.255.254. Here’s a trace showing the dropped packet:
161275.0: policy-based(ot) vpn=tunnel1 type=l2tp proto=0x0800
192.168.255.2 -> 10.25.1.252/1
vhl=45, tos=00, id=18634, frag=0000, ttl=64 tlen=84
ethernet0/3:192.168.255.2/12412->10.25.1.252/47130,1(8/0) <root>no session found
flow_first_sanity_check: in <ethernet0 3="">, out <n a="">flow_first_routing: in <ethernet0 3="">, out <n a="">search route to (ethernet0/3, 192.168.255.2->10.25.1.252) in vr trust-vr for vsd-0/flag-0/ifp-null
no route to (192.168.255.2->10.25.1.252) in vr trust-vr/0
packet dropped, no route
So, it looks like a simple Dial-Up with L2TP-IPSEC will not apply in this situation. Is there a way to make an L2TP-IPSEC Dial-Up with certificates to multiple sub-nets? Is there an easy way to get rid of the VPN Layer 3 port, e0/3? What do you guys recommend? Complex solutions are okay, but, of course simplicity would be really nice.</n></ethernet0></n></ethernet0></root>
workers last edited by
I should have mentioned that my first attempt was using a policy based VPN, and the default 0.0.0.0/0 route to e0/3.
After looking at this some more, it seems that a route based VPN is needed. Here’s two references about how to set this up:
I am trying these now, but, the packets are still trying to out e0/3.