OpenVPN Server not routing local websites
-
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
-
-
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.
-
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?
-
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.0It is getting a 192.168.2.x address when it connects.
Then why is 192.168.10.0/24 defined in server2.conf?
-
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.
-
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.
-
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).
-
I checked the firewall status and its turned inactive:
lastb0isct@miniserver:~$ sudo ufw status [sudo] password for lastb0isct: Status: inactive
Any other ideas?
-
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.
-
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
-
-
LAN IP of pfSense Box: 192.168.1.2
Ports of Server = 8080, 8081, 8082
It responds via telnet on all of those portsServer 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
-
Attached is the screenshot of my internal network.

 -
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.
-
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 ESTABLISHEDbut 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.
-
Here is the netstat -r from the server:
Destination Gateway Genmask Flags MSS Window irtt Iface
default pfroute.apt.dat 0.0.0.0 UG 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0For further testing, since i finally had the opportunity to go to a friends place and test out my VPN from my laptop I was able to hit the server just fine. I believe it might be an issues with the android client i'm using. The only thing that wasn't working from my laptop AND my android and all other clients is forwarding traffic to the internet. I can't get any external websites now. I'm sure thats a rule somewhere or a setting that I need to change.
-
For further testing, since i finally had the opportunity to go to a friends place and test out my VPN from my laptop I was able to hit the server just fine. I believe it might be an issues with the android client i'm using. The only thing that wasn't working from my laptop AND my android and all other clients is forwarding traffic to the internet. I can't get any external websites now. I'm sure thats a rule somewhere or a setting that I need to change.
Well, you have an any/any rule on your OpenVPN tab, so that rules out a firewall issue. So, that leaves routing, DNS or NAT. Go through the troubleshooting progression again.
-
Thanks for all the help. I'll diagnose again in a bit. Had an issue last night where my pfsense box froze and lost a few settings so i will have to go back in and fix everything up again.
Should have configured autobackup…