Connect from LAN to OpenVPN client — help please?d
-
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.
-
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.In testing the firewall config I've been using a mac running Viscosity, in the end we'll be using an Ubuntu system. No windows.
Thanks for the help.
Maybe I go drink vodka and watch TV now while configuring using the wizard. Seemed to work for other people. :o
-
Hmmmm. I've never used MAC as a client.
I did USE to have split routing issues with Ubuntu 10.04 but not recently.
Try it with a couple of windows clients, which are very simple, and see if thats working.
If it works, its not the servers. Its the clients.
Then vodka…
-
Fixed
Should have checked it first, but antivirus firewall on the VPN client was the culprit…..Sorry
I'm having the same issue as jg3. Ran through all the same steps to find root cause. In the end, I can't get any traffic from my internal LAN to hit the VPN client.
jg3, did you ever get this figured out?
-
jg3, did you ever get this figured out?
I did — apologies for not reporting back (bad form!). I'm glad that you solved it but for the record:
I have a 1:1 NAT for an host using an additional public IP (not the IP of the firewall). There's a corner case or two where VPN'd clients would want to reach the internal host via the public IP. So I had created another public-private 1:1 NAT rule and applied it to the OpenVPN interface. This worked to solve the aforementioned problem, but caused the host the NAT applied to not to be able to connect to VPN clients (other hosts on the internal nework could still connect to VPN clients).
So, if you've come here looking for help … about all I can tell you is: don't do that.
--jg3
