Connect from LAN to OpenVPN client — help please?d
-
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