After setting up a SSL VPN tunnel, one of the biggest complaints I get is “I cannot get to my shares”. This is because the Domain suffix has not been pushed out to their tunnel interface. This is easy to remedy, but seems to be in CLI only.
Within cli you have many options under the ssl vpn config that are not presented in the GUI.
You can edit the VPN tunnel with the command:
config vpn ssl settings
Here are a list of all the settings:
as you can see, the dns-suffix is an option, as well as DNS servers.
The Suffix option is not presented in the GUI, but the dns servers are.
The command to set the suffix is:
set dns-suffix corp.local
end
Make sure your DNS servers are also set for your internal network and it should now work without a problem.
I had to add a script into Vyatta the other day due to a bug in the OS. Well, bug might be a bad word, I think it was a driver issue with the NICs we were using. Any, the Vyatta would show the NIC as operation and up, but would not add the IP subnet configured on it into the routing table. Because of this, the default gateway would never come up. Since Vyatta is really just Debian the script creation is very simple.
This was Brocade’s VRouter 6.6 R3.
What I did was create a script in /etc/rc.d/ , change privileges, and then add it to rc.local.
Sample script
#!/bin/bash
sudo route add default gw 1.1.1.1 eth3
I save this into /etc/inid.d
then run : sudo chmod 755 /etc/init.d/Default-GW-Script
Next edit /etc/rc.local and add the script to run.
After a restart this came up no problem.
There are multiple parts to the IPSEC SIte-to-Site VPN config.
– Create access list to specify what will be encrypted
– Create access list to specify what should go over the VPN, and not be natted
– Create Phase 1 (IKE) settings and apply it to the selected interface.
– Create our transformation set (what encryption settings we will use for phase 2).
– Create Phase 2 (ESP) settings otherwise known as a Crypto map.
– Apply Crypto map settings specifying interface.
– Create the tunnel object for peer.
Config:
ASA 1 Core
Create Objects
First create the objects representing what will be found on each side of the VPN.
config t
object network Local-Subnet
subnet 10.100.1.0 255.255.255.0
object network Remote-Subnet
subnet 10.100.2.0 255.255.255.0
Encryption Access-list
Next I will create the Access list to tell the firewall what to Encrypt
access-list VPN-to-Remote extended permit ip object Local-Subnet Remote-Subnet
Now we need to make sure traffic is not being forwarded out of our WAN interface, and that the firewall knows to send it over the VPN. We do this with a “No-Nat” statement. This is different than what it once was in 8.2 and below. We will specify this with a different kind of nat statement.
No NAT
nat (inside,outside) source static Local-Subnet Local-Subnet destination static Remote-Subnet Remote-Subnet
IKE Settings
Now its time for the VPN settings!
First lets create our IKE settings and enable it on the outside interface.
crypto ikev1 enable outside
crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
Create the IPSEC transformation
crypto ipsec ikev1 transform-set transfrom esp-3des esp-sha-hmac
Crypto MAP (Phase 2)
Now lets create our Crypto map and put it all together.
crypto map VPN 10 match address VPN-to-Remote
crypto map VPN 10 set pfs
crypto map VPN 10 set peer 1.1.1.2
crypto map VPN 10 set ikev1 transform-set transfrom
crypto map VPN 10 set security-association lifetime seconds 28800
crypto map VPN 10 set security-association lifetime kilobytes 4608000
There are a few optional settings like the lifetime, by default its 28800. In this config I am just making it known that’s what its set on. Also you can set “reverse-route” which will add the route to the remote subnet into the routing table. This way you can push it out in a routing protocol.
We will also need to apply the Crypto map to the interface.
crypto map VPN interface outside
Tunnel Group/PSK
Our last step is to create the tunnel group with our Peer IP/DNS name and set the PSK.
tunnel-group 1.1.1.2 type ipsec-l2l
tunnel-group 1.1.1.2 ipsec-attributes
ikev1 pre-shared-key presharedkey
Below is the config for the Remote side
config t
object network Local-Subnet
subnet 10.100.2.0 255.255.255.0
object network Core-Subnet
subnet 10.100.1.0 255.255.255.0
access-list VPN-to-Remote extended permit ip object Local-Subnet Core-Subnet
nat (inside,outside) source static Local-Subnet Local-Subnet destination static Core-Subnet Core-Subnet
crypto ipsec ikev1 transform-set transfrom esp-3des esp-sha-hmac
crypto ikev1 enable outside
crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto map VPN 10 match address VPN-to-Core
crypto map VPN 10 set pfs
crypto map VPN 10 set peer 1.1.1.1
crypto map VPN 10 set ikev1 transform-set transfrom
crypto map VPN 10 set security-association lifetime seconds 28800
crypto map VPN 10 set security-association lifetime kilobytes 4608000
crypto map VPN interface outside
tunnel-group 1.1.1.1type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
ikev1 pre-shared-key presharedkey
The best information available for anything fortinet is always found at docs.fortinet.com. This entry will show the needed steps to create a SSL VPN via the web interface.
Creating the SSL VPN has many working parts that come together to make one of the best Remote access VPNs out there. In this example we are creating a Split tunnel VPN, and enabling Tunnel mode.
The SSL VPN is one of the best features of the device, it has an open license, so you can have as many people connect as the device hardware supports. No crazy licensing for SSL VPN as with Cisco and Sonicwall. You can also utilize the VPN to get select information to users based on their AD security group. For example if you have a business with users traveling all the time, you might have a certain portal for one group of users and have their internal bookmarks and file shares, and completely different portal for office staff users. Another great benifit is in the protocol itself, SSL is almost never blocked by outbound firewall policies. A lot of companies (hotels, hospitals) and educational institutions block IPSEC from leaving the network which stops your remote access VPN from connecting.
Steps:
1. Create Address object for SSL Subnet and Internal networks
2. Create route for new subnet
3. Create Users/User group for user authentication
4. Config the VPN Portal
5. Config the VPN settings
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
1. Create Address object for SSL Subnet and Internal networks
We will create an address object with the Subnet of our SSL VPN clients. I would recommend using a crazy private IP subnet as to not conflict with Home/work local subnets.
Then we need to create another object for our Protected subnet. This is our internal network that we want the remote user to be able to access. If there are multiple subnets it might be better to add an address object group.
2. Create route for new VPN subnet
Since the SSL VPN is a “interface” we will route our subnet across of it. Notice our device is ssl.root, and that removes our needed gateway.
3. Create Users/User group for user authentication
There are many different ways to configure authentication within the device. You can authenticate VPN users against LDAP, Radius, or local accounts. In this example I am just using local accounts, but using LDAP or Radius is a much better option. You can use just individual users, or groups to authenticate to within the VPN policy. I would go ahead and create a User group so that you can add any local, radius, or ldap users into it in the future.
I am creating a user group call SSL_VPN and in this case its just local. If I wanted to add a LDAP/Radius server to authenticate against, I could just add the remote server. If I wanted to get even more specific and say authenticate against a security group within LDAP I would just modify the remote server portion of the user group to add that.
4. Config the VPN Portal
The portal is the landing page of the SSL VPN. It is a great place to add book marks, shortcuts for RDP, or info for users. For example, we have an internal sharepoint site for users, by placing a link on the portal, users they just have to click and Whola, instant access. This is great because installing the VPN client which allows tunnel mode requires admin access to the PC. If a user is traveling or at a hotel they might not have this access. Other great uses are RDP session, and file shares. Both will launch in a Java applet window and allow you access to RDP/SMB.
We are using the “Full-access” Portal, this is just a name. I added the IP Pool for the clients to get tunnel addresses. You can customize the page to any specification. A note, you can also fully edit your VPN login page to reflect your company logo, etc. You can do this by adding in the feature under system – admin- features and enabling it.
5. Config the VPN settings
The VPN settings consists of the IP pool, Port used, encryption strength, and of course DNS/WINs servers. If you want to push your domain name so that DNS will resolve to this interface, its a CLI command. I will do another entry on it.
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
This is where we actually allow access from the internet to our VPN portal. It is also where we specify our Protected subnets, which are the subnets injected into the clients routing table. You can also specify what portal certain users will see. For example, if you had a group of teachers who needed to get to the Teacher portal, and an admins group that needs to have a different portal and ACL to get to all servers.
Notice we select VPN as type, then incoming interface. The Local protected subnets are what we are pushing into the routing table of our client.
Next create an new Authentication policy.
From here select your user group that we created earlier, if you want individual users select those as well. You can also enable UTM if you feel its needed.
Now just save all the settings
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
For the last step we need to create policies to allow traffic in both directions. By default all traffic is blocked between interfaces int he firewall. The SSL VPN is an interface, so we need to allow traffic to it.
Just create a policy with Source interface being ssl.root, and allow all traffic to your LAN (or however you see is best to secure) and then another policy from LAN to ssl.root.
Thats it! There are some optional configs dealing with Certs on both sides, and much stronger encryption methods.
Notes*
If you have a MPLS, or DMZ interface where you need VPN clients to access you will have to create another VPN policy going from WAN to – DMZ, or WAN to MPLS and just mirror the WAN-to-lan SSL VPN policy. You will also have to modify the protected subnets with that interfaces network. If anyone has trouble with this feel comment and I will explain better.
On top of that you will need to create more ssl.root to DMZ and DMZ to ssl.root policies to allow access between the interfaces.
You can monitor the firewall in much the way of a Debug command in Cisco. By using the command “Monitor firewall”. The blocked or allowed attempts will show up on the console.
You can monitor just the rule, or the whole firewall policy. By specifying the monitor to run in the background you still have control of the Vyatta.
The command is:
monitor firewall name OUTSIDE-IN background
You can also use the log keyword in the firewall rule to get the results of the rule to show up in the logs.
To give a better example lets create a firewall policy, assign it to an interface and then monitor the rule. I have two rules, one to block ICMP and one to allow everything else. To make this policy stateful I modified the firewall State-policy and set it to allow return traffic by default. Below are my firewall settings:
Now lets say I want to monitor what gets blocked in rule 5 – my block ICMP rule. I would do the following:
monitor firewall name out rule 5 – the name of my policy is “out”, rule 5 blocks ICMP.
The image shows the output. All traffic matching that rule gets displayed on the screen. This is a great way to debug firewall polices to see what gets blocked or allowed. For example, if I monitored just the firewall policy i would get all traffic allowed or blocked, if I monitored rule 10 then I would get all traffic other than ICMP which would be allowed.
Below are the “show configuration commands” of the firewall policy if you are interested.
set firewall name out rule 5 action ‘drop’
set firewall name out rule 5 log ‘enable’
set firewall name out rule 5 protocol ‘icmp’
set firewall name out rule 10 action ‘accept’
set firewall name out rule 10 log ‘enable’
set firewall name out rule 10 protocol ‘all’
set firewall name out rule 10 source address ‘192.168.60.10’
set firewall state-policy established action ‘accept’
set firewall state-policy invalid action ‘drop’
set interfaces ethernet eth1 firewall out name ‘out’
Vyatta has so many tools built in to make troubleshooting much easier. Tshark is built into Vyatta, which is just modified Debian. TCPdump is also included.
Below are some examples of how to run tshark to troubleshoot connectivity in the vyatta at a lower level.
First drop into configuration mode with the command “configure”
sudo tshark -R “ip.addr == 192.168.0.150” -r /tmp/capture.cap
This will pull all communication to and from 192.168.0.150 on any interface
sudo tshark -R “ip.addr == 192.168.0.150” -r /caps/cap1.cap
This will pull all communication from specified IP and then write it to the file /caps/cap1.cap
lets say I want to find any communication on interface eth1
sudo tshark -i eth1
What if I want to find anything coming from ip address 1.1.1.1 on tcp port 80
sudo tshark -R “ip.addr == 1.1.1.1 and tcp.port == 80”
There are a ton of combinations to help with troubleshooting. Using Tshark is a great way to see if traffic is even making it to your firewall.
Recent Comments