TLS-tunnel as interface and acting as server simultaneoulsy in 2.0.1?
-
I used 1.2.3 with TLS-tunnel as one of the interfaces (StrongVPN) for both incoming and outoing traffic (using policy routing for some outgoing traffic). If I rember correctly there was some issue that prevented med from having that set up in the fw and at the same time using the fw as VPN-server accepting roadrunners.
I remember also doing a lot of testing with other VPN alternatives at the same and having some problem getting PPTP to work when redirected etc.
The way I did then was to simply set up a second pfSense in a virtual environoment that acted as VPN server for those users connected from the outside.
Regardless of whether or not I do remember correctly about what actually did or not work in 1.2.3, does this work in 2.0.1? Can I have one or more tunnels to providers, using them as interfaces for both incoming/ougoing traffic and also using the same system for mobile users?
TIA,
-
You can have as many separate OpenVPN servers and clients as you want, with or without TLS, with or without auth (on the server side). 2.0.1 can do a lot more with OpenVPN than 1.2.x could.
-
You can have as many separate OpenVPN servers and clients as you want, with or without TLS, with or without auth (on the server side). 2.0.1 can do a lot more with OpenVPN than 1.2.x could.
Ok, and it doesn't matter if any of those client configs are system gateways then?
I got the whole thing working again yesterday in 2.0.1, having a StrongVPN tunnel set up as gateway with policy roting. However about that time the 2 OpenVPN servers I had added to the system stopped working fully. Before everything worked including surfing via the tunnels (and at first I did not have any AON added which puzzled me).
NOTE to those interested in these kinds of setups
Many seem to forget to remove the routing entries added by the "redirect-gateway def1" directive that typically is used.
I simply give the commands del net 0.0.0.0/1 and 128.0.0.0/1 to do so.
It's also easy to forget that those are added after reboots.. -
It should all work fine though with that redirect-gateway def1 on there it may be doing something funny like sending traffic back via that other tunnel instead of directly.
-
It should all work fine though with that redirect-gateway def1 on there it may be doing something funny like sending traffic back via that other tunnel instead of directly.
I have now double checked this and here are my findings.
What I need to be able to do before it's working for my needs, are all of the below:
a. tunnel working for outbound traffic
b. tunnel being able to handle directing outbound traffic via fw rules (policy routing)
c. tunnel being able to accept incoming traffic, just like the WAN,
being able to run a SMTP service behind the tunnel for instance. This means you can
(must) add port forwards and fw rules.I have ordered and set up a test tunnel.
(I'm skipping most of the setup stuff)
I disable/enable client config, triggering the tunnel to be set up.
These routing entries are added:
0.0.0.0/1 10.8.6.245 UGS 0 13 1500 ovpnc3 =>
10.8.6.241/32 10.8.6.245 UGS 0 11 1500 ovpnc3
10.8.6.245 link#15 UH 0 0 1500 ovpnc3
10.8.6.246 link#15 UHS 0 0 16384 lo0
128.0.0.0/1 10.8.6.245 UGS 0 33 1500 ovpnc3My local IP is 10.8.6.246
Tunnel remote endpoint is 10.8.6.245
Tunnel GW is 10.8.6.241I am unsure whether the advice given on the forum to choose the type of GW to "none" is the most correct one. I think I got it working using that setting though.
I rather quickly got outbound traffic working but inbound seems more uncertain than in 1.2.3, at least that's my assertion right now.
I have set up (as i did on 1.2.3) a GW with static IP, 10.8.6.246 in this case.
So basically what you do is look at the pushed info from the server side and add the local IP as the static IP address.
openvpn[14144]: PUSH: Received control message: 'PUSH_REPLY,route-delay 2,route-metric 1,dhcp-option DNS n1.nn.nn.nn,dhcp-option DNS n2.nn.nn.nn,route 10.8.6.241,topology net30,ping 10,ping-restart 60,ifconfig 10.8.6.246 10.8.6.245'
NOW: pinging in from the outside works. And connecting to a mail server works.
NOTE: I have now NOT removed the routing entries being added.However now all PCs are being pushed through the tunnel.
I now add an explicit rule forcing this one PC I'm testing on, to use the default GW instead, I even reset states to be sure. It still is pushed through the tunnel. The fw rule is not having any effect.
The only way I can get the fw rules to do their job is to remove the first and last entries above.
NOW: I remove the route entries. I don't reset states.
EFFECTS ARE:
1. policy routing now immediately starts working. I can force the PC by fw rules to use EITHER default or strongvpn gw
2. Inbound traffic stops working. All of a sudden I can't ping in or reach the mail server.I don't really see the logic in "2" happening here.
Just to test it I reset states. No different. I don't restart (can selldom restart this machine on the fly due to other users)
The "2" from above is AFAICT different from 1.2.3. I useed this exact procedure to get all a/b/c above working, but seem not to be able to do so in 2.0.1.
So, it looks like it's either:
1. all outbound traffic through tunnel and inbound traffic working
OR
2. policy routing enabled for outbound traffic and no inbound trafficINBOUND traffic above is referring to traffic INITIATED from the outside.
I'm hoping I'm missing something here and it's possible to get it working in 2.0.1. I do know that all these features were working in my 1.2.3 setup.