OpenVPN Server not routing local websites

lastb0isct · Jan 7, 2015, 1:37 AM

Hi All,

I have an issue with my OpenVPN clients connecting to my pfSense routers OpenVPN Server. Once connected i'm able to ping and ssh to all IP addresses, but when i try and connect to a LOCAL website (192.168.1.x:80) via the OpenVPN connection it just times out.

I followed this guide to get OpenVPN Server operational and setup all the clients:

https://www.highlnk.com/2013/12/configuring-openvpn-on-pfsense/

Is there anything that i'm missing here?!

lastb0isct · Jan 9, 2015, 9:51 PM

Bump?

To add a little more detail, i was able to use RDP to a machine using the VPN, but i can't get websites to show up…

marvosa · Jan 10, 2015, 1:12 AM

Simply stating it doesn't work does not provide us with anything to troubleshoot :)

The fact that everything responds to ping, ssh and RDP tells me that the tunnel is functioning as intended. Post your server1.conf. Post the IP of your server you're trying to access. Post the firewall rules on the OpenVPN tab. Disable the software firewall. Last but not least, what url are you entering to access your site?

lastb0isct · Jan 10, 2015, 12:53 AM

@marvosa:

Simple stating it doesn't work does not provide us with anything to troubleshoot :)

The fact that everything responds to ping, ssh and RDP tells me that the tunnel is functioning as intended. Post your server1.conf. Post the IP of your server you're trying to access. Post the firewall rules on the OpenVPN tab. Disable the software firewall. Last but not least, what url are you entering to access your site?

Haha, i'm aware, just curious what you'd need to know so thanks for providing that!

By server1.conf do you mean the server i'm trying to access or my OpenVPN server conf?

IP of the server i'm trying to access is 192.168.1.62, this is an ubuntu server so there should be no software firewall. I'm able to access it locally from all of my 192.168.1.x IP addresses. The url is http:\192.168.1.62:8080 or whichever port i'm trying to hit 8080-8082 i believe.

I can post the firewall rules a bit later since i'm not in front of the server at this moment.

marvosa · Jan 10, 2015, 1:48 AM

"server1.conf" meaning the contents of /var/etc/openvpn/server1.conf on PFsense.

Verify the server is using PFsense as the default gateway. (The fact that you can ping it suggests it probably is, but check anyway)
Use netstat on the server and verify what local address and port the app is listening on.
While the client is connected, verify it has a route to the subnet you're connecting to.
Verify your firewall rules are allowing the traffic from your tunnel network to your LAN
On the client, use telnet to see if the port is responding
Check your firewall logs to see if there are any blocks from your tunnel network
make sure the client is run as admin (I doubt this is it since you've already stated you can ping and ssh, but I'll throw it out there anyway)
you've also stated the software firewall on the server is disabled, but who knows… run "sudo ufw status verbose" just to verify

Have you tried simply restarting apache?

lastb0isct · Jan 15, 2015, 2:22 AM

Attached is my server2.conf (replaced it as .txt) and a picture of the rules. I only have one server, but i guess it was created as the second one.

I'm able to access the webpages from any other machine. If I RDP into a machine over the OpenVPN connection i'm able to hit any webpage i want still, so i don't think apache restart would work.

1. It is using pfsense as the default gateway
2-3. I'll have to test
4. I am able to hit machines, ssh to machines, etc…just not hit webpages.
5. will test
6. I will do this
7. Yep, it is
8. This won't run in the pfsense shell.

Server2.conf:

dev ovpns2
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 104.172.13.57
tls-server
server 192.168.10.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
username-as-common-name
auth-user-pass-verify /var/etc/openvpn/server2.php via-env
tls-verify /var/etc/openvpn/server2.tls-verify.php
lport 11111
management /var/etc/openvpn/server2.sock unix
max-clients 3
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.1.2"
push "redirect-gateway def1"
client-to-client
ca /var/etc/openvpn/server2.ca 
cert /var/etc/openvpn/server2.cert 
key /var/etc/openvpn/server2.key 
dh /etc/dh-parameters.4096
tls-auth /var/etc/openvpn/server2.tls-auth 0
comp-lzo
persist-remote-ip
float
topology subnet

Firewall Rules:

marvosa · Jan 26, 2015, 8:42 PM

The firewall rule on your WAN tab looks right… what about the LAN and OpenVPN tab?

Your LAN subnet is pretty common, make sure your client is not connecting from 192.168.1.0/24.

I'm able to access the webpages from any other machine. If I RDP into a machine over the OpenVPN connection i'm able to hit any webpage i want still, so i don't think apache restart would work.

Just to clarify, your successful connections from inside your LAN… you are using the same URL right? Or are you using a hostname?
Restarting apache would take about 5 sec, might as well try it. When something isn't working like it should at work, one of the first things people do is bounce the service to see if it comes back. If that doesn't work they bounce the box… so it may work... it may not... but it certainly is not going to hurt anything

8. This won't run in the pfsense shell.

Run it on your server… not PFsense

lastb0isct · Jan 26, 2015, 8:38 PM

Sorry for the late reply, been really busy with stuff. Good idea to check on the LAN/OpenVPN tab. I will do that when i get home.

To clarify, the specific client i'm having issues with is an android client (my phone). It is getting a 192.168.2.x address when it connects.

Yes, they're all using the same URL. I like using IPs for the URLs, which is what i use on both.

lastb0isct · Jan 29, 2015, 2:13 AM

It doesn't look like there is much in these other tabs. Do you know what i'd have to add to allow this traffic?

Derelict · Jan 29, 2015, 4:12 AM

@marvosa:

Your LAN subnet is pretty common, make sure your client is not connecting from 192.168.1.0/24.

+1 Renumber your network off the same IP scheme used by 10s of millions of little blue routers all over the world.

Some random suggestions:

172.29.40.0
192.168.169.0

It is getting a 192.168.2.x address when it connects.

Then why is 192.168.10.0/24 defined in server2.conf?

marvosa · Jan 29, 2015, 2:47 PM

As Derelict said, your config is handing out 192.168.10.0/24 addresses, so if you're getting a 192.168.2.0/24 address you're connecting to the wrong server.

You obviously have multiple servers configured and you are making a successfully connection (verified by an IP in the 192.168.2.0/24 range), so I'm betting you simply exported the config for the wrong server.

lastb0isct · Jan 30, 2015, 3:34 PM

Sorry, my mistake.

I am connection to 192.168.10.x subnet. I was getting the 192.168.10.2 IP assigned to my client.

EDIT: Also, i'll work on renumbering my network. Its a good suggestions, no reason to be that vulnerable. But do you guys notice anything else that is needed to pass the traffic from the OpenVPN to my LAN?

I am having issues specifically with my android phone connecting over VPN having this access.

rin_tinn · Jan 30, 2015, 10:43 PM

I was having the same problem. Turned out the firewall was enabled on my Ubuntu server (which I knew, but forgot to punch a hole through).

If you log into your Ubuntu server and issue the command "sudo ufw status" it will tell you if the firewall service is active or not. If it is active, you'll need to have rules which allow access from the VPN network you set in the "IPv4 Tunnel Network" option (VPN >> OpenVPN >> Server).

lastb0isct · Feb 1, 2015, 9:56 PM

I checked the firewall status and its turned inactive:

lastb0isct@miniserver:~$ sudo ufw status
[sudo] password for lastb0isct:
Status: inactive

Any other ideas?

rin_tinn · Feb 2, 2015, 3:42 PM

It is interesting that the port in your screen capture of your firewall rule is 11111 and not 1194. Wonder if that has something to do with it? Pretty new to pfSense myself, so I'm not sure.

What VPN client are you using to connect with? I was trying to connect with Tunnelblick, but could not get it to work well. After I switched over to Viscosity VPN client, I haven't had any other problems.

marvosa · Feb 3, 2015, 4:36 AM

Lets get a few things out of the way:

Post a network map, so we know how things are connected
What is the LAN IP of your PFsense box?
Post the routing table of your server. Is the IP still 192.168.1.62?
Post the routing table of your connected client
What port is your app listening on (80?, 8080?, 8081?, 8082?)?
From the client, does the port responds via telnet?
Post a traceroute from the client to the server

lastb0isct · Feb 7, 2015, 11:05 PM

LAN IP of pfSense Box: 192.168.1.2
Ports of Server = 8080, 8081, 8082
It responds via telnet on all of those ports

Server routing table:

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 192.168.1.62:8082       192.168.1.62:52465      TIME_WAIT  
tcp        0      0 192.168.1.62:8082       192.168.1.62:52466      TIME_WAIT  
tcp        0      0 localhost:58846         localhost:52205         ESTABLISHED
tcp        0      0 192.168.1.62:887        192.168.1.35:nfs        ESTABLISHED
tcp        0    236 192.168.1.62:ssh        192.168.10.2:65407      ESTABLISHED
tcp        0      0 192.168.1.62:tproxy     192.168.10.2:64229      ESTABLISHED
tcp        0      0 192.168.1.62:52467      192.168.1.62:8082       TIME_WAIT  
tcp        0      0 192.168.1.62:tproxy     192.168.10.2:64232      ESTABLISHED
tcp        0      0 192.168.1.62:http-alt   192.168.1.127:2278      ESTABLISHED
tcp        0      0 192.168.1.62:tproxy     192.168.10.2:64227      ESTABLISHED
tcp        0      0 192.168.1.62:tproxy     192.168.10.2:64230      ESTABLISHED
tcp        1      0 192.168.1.62:36767      vps1.v-u.be:http        CLOSE_WAIT 
tcp        0      0 192.168.1.62:mysql      192.168.1.41:36738      ESTABLISHED
tcp        0      0 192.168.1.62:tproxy     192.168.10.2:64228      ESTABLISHED
tcp        0      0 192.168.1.62:8082       192.168.1.62:52464      TIME_WAIT  
tcp        0      0 localhost:52205         localhost:58846         ESTABLISHED
tcp        0      0 192.168.1.62:http-alt   192.168.10.2:64268      ESTABLISHED
tcp        0      0 192.168.1.62:http-alt   192.168.10.2:64266      ESTABLISHED
tcp        0      0 192.168.1.62:8082       192.168.1.62:52463      TIME_WAIT  
tcp        0      0 192.168.1.62:mysql      192.168.1.40:34729      ESTABLISHED
tcp        0      0 192.168.1.62:http-alt   192.168.10.2:64267      ESTABLISHED
tcp        0      0 192.168.1.62:tproxy     192.168.10.2:64231      ESTABLISHED

Client routing table:

Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)    
tcp4       0      0  192.168.10.2.65281     64.210.194.87.https    SYN_SENT   
tcp4       0      0  192.168.10.2.65280     17.110.242.14.https    SYN_SENT   
tcp4       0      0  192.168.10.2.65279     17.110.242.14.https    SYN_SENT   
tcp4       0      0  192.168.10.2.65278     lax02s20-in-f24..https SYN_SENT   
tcp4       0      0  192.168.10.2.65277     216.178.109.197.https  SYN_SENT   
tcp4       0      0  192.168.10.2.65276     lax02s20-in-f24..https SYN_SENT   
tcp4       0      0  192.168.10.2.65275     lax17s05-in-f4.1.https SYN_SENT   
tcp4       0      0  192.168.10.2.65274     lax02s19-in-f8.1.https SYN_SENT   
tcp4       0      0  192.168.10.2.65273     pa-in-f188.1e100.5228  SYN_SENT   
tcp4       0      0  192.168.10.2.65272     pc-in-f189.1e100.https SYN_SENT   
tcp4       0      0  192.168.10.2.65271     pc-in-f189.1e100.https SYN_SENT   
tcp4       0      0  192.168.10.2.65270     lax02s19-in-f8.1.https SYN_SENT   
tcp4       0      0  192.168.10.2.65269     lax17s05-in-f4.1.https SYN_SENT   
tcp4       0      0  192.168.10.2.65268     pa-in-f188.1e100.5228  SYN_SENT   
tcp4       0      0  192.168.10.2.65267     pc-in-f189.1e100.https SYN_SENT   
tcp4       0      0  192.168.10.2.65266     pc-in-f189.1e100.https SYN_SENT   
tcp4       0      0  192.168.0.18.65263     173.112.255.173..https ESTABLISHED
tcp4       0      0  localhost.menandmice-d localhost.65262        ESTABLISHED
tcp4       0      0  localhost.65262        localhost.menandmice-d ESTABLISHED
tcp4       0    282  192.168.0.18.65261     www.tunnelblick..https ESTABLISHED
tcp4       0      0  192.168.0.18.65096     173.243.12.181.https   ESTABLISHED
tcp4       0    106  192.168.0.18.65081     17.110.228.19.5223     ESTABLISHED
tcp4       0      0  192.168.10.2.64068     192.168.1.35.ftp       ESTABLISHED
tcp4       0      0  192.168.1.210.54971    104.130.144.67.https   CLOSE_WAIT 
tcp4       0      0  localhost.26164        localhost.49375        ESTABLISHED
tcp4       0      0  localhost.49375        localhost.26164        ESTABLISHED
tcp4       0      0  localhost.29754        localhost.49152        ESTABLISHED
tcp4       0      0  localhost.49152        localhost.29754        ESTABLISHED
udp6       0      0  *.64174                *.*                               
udp4       0      0  *.64174                *.*                               
udp6       0      0  *.50856                *.*                               
udp4       0      0  *.50856                *.*                               
udp6       0      0  *.50308                *.*                               
udp4       0      0  *.50308                *.*                               
udp4       0      0  *.50160                *.*                               
udp4       0      0  *.*                    *.*                               
udp4       0      0  192.168.10.2.ntp       *.*                               
udp4       0      0  192.168.0.18.ntp       *.*                               
udp6       0      0  *.61890                *.*                               
udp4       0      0  *.61890                *.*

Traceroute from client to server:

 traceroute 192.168.1.62
traceroute to 192.168.1.62 (192.168.1.62), 64 hops max, 52 byte packets
 1  192.168.10.1 (192.168.10.1)  32.289 ms  31.075 ms  23.009 ms
 2  192.168.1.62 (192.168.1.62)  22.792 ms  22.625 ms  21.795 ms

lastb0isct · Feb 7, 2015, 11:12 PM

Attached is the screenshot of my internal network.

![Screen Shot 2015-02-07 at 3.05.13 PM.png](/public/imported_attachments/1/Screen Shot 2015-02-07 at 3.05.13 PM.png)
![Screen Shot 2015-02-07 at 3.05.13 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-02-07 at 3.05.13 PM.png_thumb)

Derelict · Feb 7, 2015, 11:22 PM

A network diagram without at least subnets and interface addresses is about worthless.

See the diagram in my sig for an example of something that might help people solve your problem.

marvosa · Feb 8, 2015, 7:51 AM

I agree with Derelict, a network map with IP info would be helpful. Also, those are not routing tables… you've given us a list of what is connected. The command you're looking for is "netstat -r"

It looks like you have a successful connections to port 8080:

tcp 0 0 192.168.1.62:http-alt 192.168.10.2:64268 ESTABLISHED
tcp 0 0 192.168.1.62:http-alt 192.168.10.2:64266 ESTABLISHED

but may be having issues with 8082.

These connections are more telling though:

tcp 0 0 192.168.1.62:tproxy 192.168.10.2:64229 ESTABLISHED
tcp 0 0 192.168.1.62:tproxy 192.168.10.2:64227 ESTABLISHED
tcp 0 0 192.168.1.62:tproxy 192.168.10.2:64230 ESTABLISHED

"tproxy" is apparently short for "Transparent Proxy", so it looks like you have squid running in transparent mode and it's intercepting/redirecting your requests. Start by disabling squid.