Connect from LAN to OpenVPN client — help please?d
-
Hello,
I would like to be able to connect from systems on the LAN to OpenVPN clients, but it is not working. I need help with how best to configure this. Connectivity from OpenVPN clients to the LAN is working fine. OpenVPN and LAN clients can reach the Internet fine, and 1:1 nat for the LAN host is working fine also. The pfSense LAN interface is the default gateway for outbound traffic from the LAN.
LAN is 10.1.6.0/24 and OpenVPN clients get addresses in the 10.1.4.0/24 range. So a host 10.1.6.21 should be able to SSH to 10.1.4.6, if I have the right settings — but I can't seem to figure out what those are.
I think this would work if I switched the OpenVPN setting Device Mode from TUN to TAP, but I don't want to incur lots of broadcast traffic on VPN client connections.
Other things left to change don't seem to indicate a best option - ProxyArp for the 10.1.4.0/24 on the LAN address? NAT traffic coming in on the OpenVPN interface?
Incidentally, I have the "Allow communication between clients connected to this server" option checked, but it doesn't seem to work. Connected OpenVPN clients cannot communicate (eg, ssh, http) to other connected clients. Firewall rules permit anything on LAN and OpenVPN interfaces. Outbound NAT is set to automatic.
Any hints or pointers are appreciated.
-
Don't forget firewalls on the clients - maybe that is what is blocking the traffic?
Don't forget to make sure the service your trying to connect to is actually listening on vpn IP your client gets.
I can ping my vpn clients just fine from the lan network
ping 10.0.200.6
PING 10.0.200.6 (10.0.200.6) 56(84) bytes of data.
64 bytes from 10.0.200.6: icmp_req=1 ttl=127 time=123 ms
64 bytes from 10.0.200.6: icmp_req=2 ttl=127 time=119 ms
64 bytes from 10.0.200.6: icmp_req=3 ttl=127 time=120 ms -
Don't forget firewalls on the clients - maybe that is what is blocking the traffic?
Don't forget to make sure the service your trying to connect to is actually listening on vpn IP your client gets
Thanks for the reply. Those are valid concerns, but I have verified that's not the issue in this case.
My VPN interface and IP
VPNclientHost:~ jg3$ ifconfig tun0 tun0: flags=8851 <up,pointopoint,running,simplex,multicast>mtu 1500 inet 10.1.4.6 --> 10.1.4.5 netmask 0xffffffff open (pid 14805)</up,pointopoint,running,simplex,multicast>Which I can ping locally:
VPNclientHost:~ jg3$ ping 10.1.4.6 PING 10.1.4.6 (10.1.4.6): 56 data bytes 64 bytes from 10.1.4.6: icmp_seq=0 ttl=64 time=18.789 ms 64 bytes from 10.1.4.6: icmp_seq=1 ttl=64 time=20.629 ms ^C --- 10.1.4.6 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 18.789/19.709/20.629/0.920 msAnd pull a webpage from the local webserver using the VPN address:
VPNclientHost:~ jg3$ curl 10.1.4.6 # It works!(I haven't demonstrated it here, but other machines in the VPNclientHost's LAN can hit the webserver on this VPN address also.)
So now connecting from the LAN machine…
I attempt to connect to the webserver on the OpenVPN client:
jg3@LAN_Host:~$ telnet 10.1.4.6 80 Trying 10.1.4.6...Watching traffic on the LAN interface using Diagnostics:Packet Capture in pfSense:
14:31:54.340511 IP 10.1.6.21.50921 > 10.1.4.6.80: tcp 0 14:31:55.338860 IP 10.1.6.21.50921 > 10.1.4.6.80: tcp 0 14:31:57.342821 IP 10.1.6.21.50921 > 10.1.4.6.80: tcp 0Same thing again, but watching traffic on the OpenVPN interface:
(no packets are shown)From this I can deduce that pfSense is blocking LAN-sourced traffic to the OpenVPN clients. But my firewall rules on the LAN and OpenVPN interfaces are (default) set to allow everything, so I don't see what would block it.
From the host on the LAN, I can't connect to services on the OpenVPN clients.
Have you other services to demonstrate besides ping?
Can you demonstrate connecting to them from a host in the LAN?
Is there something in my configuration you recommend I check?
What Device Mode are you using in your OpenVPN setup?
How do you have your OpenVPN configured?Thanks.
edit: Correctly obfuscated IP addresses in the curl/telnet examples.
-
Ok for starters you state that the vpn address
inet 10.1.4.6
But then your trying to connect to
telnet 10.16.2.6 80
curl 10.16.2.6Where are you watching the openvpn interface? On pfsense? If you trying to go to 10.16.2.6 why would it go out your openvpn inteface if 10.1.4.6 is the openvpn network? If you want to route to network on the other side of the tunnel you would have to create a route for this 10.16.2 network and the other side would have to route it back.. Are you trying to setup a site to site connection, or are your clients just road warriors?
What is the mask on the clients normal interface IP? Depending on the mask of 10.16.2.6 you could have overlap of ips. /8 on that would not be good for example.
Sure let me fire up a service on my client and connect too it for you.. But if your can ping it, I would think your just maybe using the wrong IP from the examples you gave with curl and telnet.
-
sorry, the 10.16 addresses are the actual addresses. I'm required to obfuscate even RFC1918 addresses in production.
the telnet/curl connections are correct.
:-[
-
"I'm required to obfuscate even RFC1918 addresses in production."
What?? So you have idiots in your security dept ;)
-
Are you trying to setup a site to site connection, or are your clients just road warriors?
What is the mask on the clients normal interface IP?
I have one remote OpenVPN client machine (not a router so not a candidate for a site-site VPN) that I want to use for offsite backup with rsync. The rsync connection will be initiated from the server on the LAN, so she needs to be able to connect out to that client.
Later, we'll have an application that will connect out to road warriors. That will render a similar sort of problem, but that's not the precise use case now.
The mask on the internal network is /24 and the OpenVPN server is configured to draw from a /24.
Thanks for taking the time to reply (and read my post details!) ;)
-
"I'm required to obfuscate even RFC1918 addresses in production."
What?? So you have idiots in your security dept ;)
s/security/legal/ … but yes. (-;
-
Ahhhhh - Are they as good with networking as they are with security and legal?
Maybe they can help? haha. :P
I used to work with imbeciles like that too… No more though.
Sorry - Its just a little funny. If you are going to mask IPs and such, use find/replace so they make good sense in the end.
-
Ahhhhh - Are they as good with networking as they are with security and legal?
Maybe they can help? haha. :P
I used to work with imbeciles like that too… No more though.
Congrats! I don't want to get off topic but it works like this: As consultants, we have a series of non-disclosure promises we make to our customers and to simplify* the legal language we don't differentiate between RFC1918 and public IPs. When asked "but they're [RFC1918] addresses!" Legal says, "obfuscate them anyway." Translation: 'I want you to deal with a headache now so I don't have to later'.
Also, it makes for good conversation at the pub.
- Possibly out of ignorance, we might never be sure. 8)
-
You know what? I have done this with pfsense 2.03 and openvpn using same settings and it worked fine.
Clients logging onto my pfsense openvpn from the internet. My ubuntu machine on the LAN could SSH to them, even directly access their shares. All this assumes you are using IPs to directly access everything and not any domain names or anything. Between clients also worked fine.
I did give clients a DNS Default Domain , I did use TUN (not TAP), I did force all client traffic through tunnel, I did Provide a virtual adapter IP address to clients plus the other things you already talked about. It was easy. No special effort required. The "Wizard" takes care of all that well.
I actually had to make firewall rules to make it so this wasn't possible.Did you use the pfsense openvpn client export tool to export your clients or did you download it somewhere else?
I haven't tried it with 2.1
-
You know what? I have done this with pfsense 2.03 and openvpn using same settings and it worked fine.
… The "Wizard" takes care of all that well.
I actually had to make firewall rules to make it so this wasn't possible.Did you use the pfsense openvpn client export tool to export your clients or did you download it somewhere else?
I haven't tried it with 2.1
I'm running 2.0.3 here, too. I did use the export tool.
What firewall rules did you add to prevent this?
I didn't use the wizard to set up the VPN server in the first place, maybe I'll run through that and see if I'm missing something obvious.
-
Well - I added a rule on the LAN to block anything with source Openvpn subnet. Put it on top.
Also added a rule on the Openvpn firewall tab to block anything from Source LAN subnet. Also on top.It was incredibly not complex. I think I may have even been drunk at the time and simultaneously watching a Supernatural rerun online…
They wouldn't let me drink vodka while maintaining a network on a Friday night in the government - very depressing. Legal. Security.
I guess.
-
I set up a second OpenVPN server with the wizard as discussed, that demonstrated the same issue.
I have added some explicit "pass and log" rules to the firewall for traffic with a source or dest of port 80 to the OpenVPN subnet and coming back in on that interface, but that didn't show anything new. In summary, traffic passes in via the LAN interface but does not go out via the OpenVPN interface.
Not surprisingly, tcpdump'ing on the OpenVPN client's tun interface indicates traffic originating on the LAN doesn't make it there, either.
If your config had this working, would you mind sharing your the section of your /conf/config.xml between <openvpn>and</openvpn> either here or in a PM?
-
Have you tried adding a static route?
My config is 100% same as yours. I didn't do a single thing to make this work.
You must have something special going on on your network. -
I haven't tried adding a static route, but I don't mind trying.
I suppose route 10.1.4.6 -> 10.1.4.5 since .6 is the pfSense end of the tun0 and .5 is the client?
-
I don't know. You are the one who knows where you put your IPs.
-
So I didn't do anything but run through the wizard with my openvpn setup running
2.1-RC1 (i386)
built on Thu Aug 1 19:03:40 EDT 2013
FreeBSD 8.3-RELEASE-p9So I fired up a service (ftp)
c:\>netstat -an | find ":21" TCP 0.0.0.0:21 0.0.0.0:0 LISTENING TCP [::]:21 [::]:0 LISTENING c:\>ipconfig windows IP Configuration ethernet adapter vpn: Connection-specific DNS Suffix . : local.lan IPv4 Address. . . . . . . . . . . : 10.0.200.6 Subnet Mask . . . . . . . . . . . : 255.255.255.252 Default Gateway . . . . . . . . . :So on my linux box on my remote network.. And hitting ftp to this box which is a road warrior connection – you can see the above IP it has for the vpn connection.. BTW that 10.0.200.6 address you can DDOS the shit out of it!! Port SCAN IT, look it up to find out what where I live, etc. etc.. ;) Feel free to do the same to my 192.168.1.7 IP you see there.. Those are my actual IPs mind you -- didn't do any hiding or changing of any of the octets.. Hire whatever Chinese hacker squads you want to go after it -- hehehe, sorry stupidity in policies make me giddy ;)
bing bang zoom
ftp 10.0.200.6 Connected to 10.0.200.6. 220-FileZilla Server version 0.9.41 beta 220-written by Tim Kosse (Tim.Kosse@gmx.de) 220 Please visit http://sourceforge.net/projects/filezilla/ Name (10.0.200.6:johnpoz):So you got something not right.. But there is nothing special you should have to do.
So under diag, packet capture picked my openvpn as what to sniff on.. and
15:56:25.877674 IP 10.0.200.6.21 > 192.168.1.7.41865: tcp 42
15:56:25.877743 IP 10.0.200.6.21 > 192.168.1.7.41865: tcp 45
15:56:25.877749 IP 10.0.200.6.21 > 192.168.1.7.41865: tcp 61
15:56:25.878469 IP 192.168.1.7.41865 > 10.0.200.6.21: tcp 0
15:56:25.878471 IP 192.168.1.7.41865 > 10.0.200.6.21: tcp 0
15:56:25.878472 IP 192.168.1.7.41865 > 10.0.200.6.21: tcp 0If your not seeing anything.. Then are you sure your box that is trying to talk to the vpnclient that is connected is routing that traffic to pfsense.. Do you have any funky rules on your openvpn tab, or floating or lan interface that your client that is wanting to talk to your vpnclient is hitting?
my openvpn rule is IPV4 * * * * * and was created by the openvpn wizard
-
Also, if its a VPN client on a windows machine, was it install as admin and is the client running as admin?
If not, you will APPEAR to be connected, but nothing is really routed to, from or through pfsense/openvpn.I don't know what to tell you. Any "special" setting I'd give you would probably hurt more than help.
Its pretty much default and works. -
… are you sure your box that is trying to talk to the vpnclient that is connected is routing that traffic to pfsense.. Do you have any funky rules on your openvpn tab, or floating or lan interface that your client that is wanting to talk to your vpnclient is hitting?
Yep, the LAN client has pfSense as the default gateway and the only other route it has is for the local subnet. No funky rules on the OpenVPN tab or any floating rules at all. The LAN rules for now are all accepts.
It's. just. really. weird.
Thanks for spending the time to document this. The biggest difference I can see from your setup is you're running 2.1.RC1 and I'm running 2.0.3-R.
