Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Configure VPN in Juniper SSG5
Hello,
I am looking for help to configure Juniper SSG5 VPN. we have 1 locally hosted website. we want our remote laptop user to access this website when they are out of office. our lan IP is 192.168.0.1 and server IP is 192.168.0.15 Firewall local IP is 192.168.0.8. Firewall is direct connected with service provider WAN IP.
I am looking for help to configure Juniper SSG5 VPN. we have 1 locally hosted website. we want our remote laptop user to access this website when they are out of office. our lan IP is 192.168.0.1 and server IP is 192.168.0.15 Firewall local IP is 192.168.0.8. Firewall is direct connected with service provider WAN IP.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
how are you accessing it for configuration, are you using the serial/console port or the web interface or ssh cli?.
https://kb.juniper.net/InfoCenter/index?page=content&id=kb8402
https://kb.juniper.net/InfoCenter/index?page=content&id=kb8402
Your local IP choice, 192.168.0.0/24 could be problematic as it is a common LAN IP oin homes, the IP segments must be different.
You are setting up a remote VPN
Does your system have a static ip?
Juniper.net and other resources of examples.....
You should
Sire A Your ssg5 location
wAN Ip: c.c.x.x
LAN segment: 192.168.0.0/24
Remote user:
Any source
LAN IP: ?
IPSec policy, using VPN client or is provided?
Key length,
Pre shared:
Key lifetime
Phase1:
Phase2:
You have to mirror the settings...
You are setting up a remote VPN
Does your system have a static ip?
Juniper.net and other resources of examples.....
You should
Sire A Your ssg5 location
wAN Ip: c.c.x.x
LAN segment: 192.168.0.0/24
Remote user:
Any source
LAN IP: ?
IPSec policy, using VPN client or is provided?
Key length,
Pre shared:
Key lifetime
Phase1:
Phase2:
You have to mirror the settings...
My remote user don't have static IP. Please suggest what should i do.
i have 15-20 remote user with dynamic connection to connect my LAN. they may have poor internet. what should i opt Policy base or route base.
i have 15-20 remote user with dynamic connection to connect my LAN. they may have poor internet. what should i opt Policy base or route base.
Of course it would be much easier if you just "published" the web site by using port forwarding, but that will bring in some secuirty and privacy issues ...
Is the client running W10? Then you could use the integrated IPSec IKEv2 client. Otherwise you have to install IPSec software like the free ShrewSoft VPN, or a commercial one like NCP (very good support, even in trial phase).
But be warned, it might become a PITA to get it working. Testing definitely is a PITA, as you need to be in a different network for that.
Is the client running W10? Then you could use the integrated IPSec IKEv2 client. Otherwise you have to install IPSec software like the free ShrewSoft VPN, or a commercial one like NCP (very good support, even in trial phase).
But be warned, it might become a PITA to get it working. Testing definitely is a PITA, as you need to be in a different network for that.
Dial-in clients don't neeed to have static IPs, but your main site should have one, otherwise the configuration is getting more complex.
Unless you have complex configuration restrictions in mind, I would stay with a policy based VPN.
Unless you have complex configuration restrictions in mind, I would stay with a policy based VPN.
Policy based, my first suggestion would be to get away from the 192.168.0.0/24 on your side to
X>=30 if using the 192.168.x.0/24
10.0.0.0/24 is also used by sone cable providers.
You are setting up a dual-up , policy based should be fine.
The link I posted last deals with setting up one dial-up VPN as a single policy/setup using xauth to differentiate between/among the users.
Simpler, I.e. Have a single dial-up VPN, and manage user accounts
Versus setting up a distinct VPN dial-up for each user, then deactivate the policy when the user is no longer authorized.
The prior, disabling the user, will result in the user being unable to setup the VPN (authorize)
X>=30 if using the 192.168.x.0/24
10.0.0.0/24 is also used by sone cable providers.
You are setting up a dual-up , policy based should be fine.
The link I posted last deals with setting up one dial-up VPN as a single policy/setup using xauth to differentiate between/among the users.
Simpler, I.e. Have a single dial-up VPN, and manage user accounts
Versus setting up a distinct VPN dial-up for each user, then deactivate the policy when the user is no longer authorized.
The prior, disabling the user, will result in the user being unable to setup the VPN (authorize)
what will be the issue if i continue using 192.160.0.0/24.
And please also advise why to use policy base over route base.
i would like to go with different setup key for different user so i can restrict user when we want to.
And please also advise why to use policy base over route base.
i would like to go with different setup key for different user so i can restrict user when we want to.
When using XAuth (= explicit user authnentication), you restrict the user account, not the VPN. You can create a local user account setup - and have full and separate control on the device - or use RADIUS to authenticate against the domain account.
In both cases you do not need to use different keys for users.
Policy based VPN is just simpler, and allows for direct control in the GUI. A route based VPN is more complex, as you have to consider more levels of processing with different precedence and a particular sequence. Policies also have the advantage that you can just disable the policy to prevent from general dial-in.
If you still want to use different VPN tunnels for different user (groups), you can switch the policy for those on/off as you like.
In both cases you do not need to use different keys for users.
Policy based VPN is just simpler, and allows for direct control in the GUI. A route based VPN is more complex, as you have to consider more levels of processing with different precedence and a particular sequence. Policies also have the advantage that you can just disable the policy to prevent from general dial-in.
If you still want to use different VPN tunnels for different user (groups), you can switch the policy for those on/off as you like.
Regarding the network: You get into serious trouble as soon as someone dialing in is using the same network. Tendency is to use IP addresses starting at the lower end, so the router will be .1, servers are usually at the lower end, and clients somewhere higher.
So imagine you have a common home network setup of router = 192.168.0.1, client PC = 192.168.0.2. You want to establish the VPN connection to RDP into 192.168.0.2, which is a server. That would not work, no matter what you do. If the single addresses are not the same, you can apply some hacking and routing tricks, but that is flaky and likely to fail for other dial-in users.
Applying destination NAT to everything having to pass the VPN is one hack. E.g. you would translate all your office addresses to 172.27.14.0/24 in the VPN policy - you then would have to use those addresses on VPN, without a working name resolution, and many issues more.
So really, the best you can do is move your office network to some random address like the one I used above.
So imagine you have a common home network setup of router = 192.168.0.1, client PC = 192.168.0.2. You want to establish the VPN connection to RDP into 192.168.0.2, which is a server. That would not work, no matter what you do. If the single addresses are not the same, you can apply some hacking and routing tricks, but that is flaky and likely to fail for other dial-in users.
Applying destination NAT to everything having to pass the VPN is one hack. E.g. you would translate all your office addresses to 172.27.14.0/24 in the VPN policy - you then would have to use those addresses on VPN, without a working name resolution, and many issues more.
So really, the best you can do is move your office network to some random address like the one I used above.
192.160.0.0/24 is a public IP space and is allocated to
You have to pick IPs from the PRIVATE IP Space
192.168.0.x-192.168.255.x
172.16-31.y.x
10.x.x.x
You have to pick IPs from the PRIVATE IP Space
192.168.0.x-192.168.255.x
172.16-31.y.x
10.x.x.x
in below link:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB14883&actp=METADATA
Where i suppose to do below configuration:
From where i download Netscreen. Is there any license required or any alternate software.
Configuration of NetScreen-Remote Side:
Create New Policy by clicking the New Connection icon on upper left corner. Label this new connection Corporate
On Remote Party Identity and Addressing
Set ID Type: IP Subnet
Enter Subnet: 172.16.10.0
Enter Netmask: 255.255.255.0
Click Connect using Secure Gateway Tunnel
Enter ID Type: IP Address: 1.1.1.1
Expand the connection Corporate
Click Security Policy
Select Phase 1 Negotiation Mode: Aggressive
De-Select Enable Perfect Forward Secrecy (PFS)
De-select "Enable Replay Detection"
Click My Identity
Select Certificate: None
ID Type: Email address: sales@ns.com
Click Pre-Shared Key
Click Enter Key
Click OK
Enter the Pre-shared key sharedikeid
Expand Security Policy
Expand Authentication (Phase 1)
Select Proposal 1
Authentication Method: Pre-Shared Key;Extended Authentication
Encryption Alg: Triple DES
Hash Alg: SHA
SA Life: Unspecified
Key Group: Diffie-Hellman Group 2
Expand Key Exchange (Phase 2)
Select Proposal 1
Encrypt Alg. Triple DES
Hash Alg. SHA
Encapsulation: Tunnel
Click Save
https://kb.juniper.net/InfoCenter/index?page=content&id=KB14883&actp=METADATA
Where i suppose to do below configuration:
From where i download Netscreen. Is there any license required or any alternate software.
Configuration of NetScreen-Remote Side:
Create New Policy by clicking the New Connection icon on upper left corner. Label this new connection Corporate
On Remote Party Identity and Addressing
Set ID Type: IP Subnet
Enter Subnet: 172.16.10.0
Enter Netmask: 255.255.255.0
Click Connect using Secure Gateway Tunnel
Enter ID Type: IP Address: 1.1.1.1
Expand the connection Corporate
Click Security Policy
Select Phase 1 Negotiation Mode: Aggressive
De-Select Enable Perfect Forward Secrecy (PFS)
De-select "Enable Replay Detection"
Click My Identity
Select Certificate: None
ID Type: Email address: sales@ns.com
Click Pre-Shared Key
Click Enter Key
Click OK
Enter the Pre-shared key sharedikeid
Expand Security Policy
Expand Authentication (Phase 1)
Select Proposal 1
Authentication Method: Pre-Shared Key;Extended Authentication
Encryption Alg: Triple DES
Hash Alg: SHA
SA Life: Unspecified
Key Group: Diffie-Hellman Group 2
Expand Key Exchange (Phase 2)
Select Proposal 1
Encrypt Alg. Triple DES
Hash Alg. SHA
Encapsulation: Tunnel
Click Save
Premium Content
You need an Expert Office subscription to comment.Start Free Trial