WebGui inaccessible from LAN after OpenVPN server enabled…Huh??
-
After following the following guide, my web configurator is consistently returning a "503-Service Not Available." If I reboot pfSense I can login initially but after a little while I get the error message again. Not only is pfSense inaccessible via the web gui, but I also lose connectivity via IPMI on my LAN even though I can ping the IPMI address.
I restored a backup to an earlier config and everything is fine after that. Tested configuring again and as soon as I configure the OpenVPN server (and nothing else) I get the same issue witht he web configurator being inaccessible.
What am I missing?
-
Sounds like your subnets might be overlapping or something.
What are your interface subnets, your OpenVPN tunnel network subnets, and any OpenVPN remote networks. Please include netmasks.
-
Sounds like your subnets might be overlapping or something.
What are your interface subnets, your OpenVPN tunnel network subnets, and any OpenVPN remote networks. Please include netmasks.
I'm on version 2.2.2.
-
Yeah. What are all the other subnets in the router? Be specific.
-
Or is your IPMI somehow taking over your LAN connection? Is there a dedicated port? Is the "BIOS" set for dedicated?
-
Yeah. What are all the other subnets in the router? Be specific.
The only other subnet on the router is my WAN connection which is 108.x.x.x/24 assigned via DHCP by my ISP.
Or is your IPMI somehow taking over your LAN connection? Is there a dedicated port? Is the "BIOS" set for dedicated?
I checked and in the BIOS it was set to "unspecified" so I set it to static. Not sure whay setting an OpenVPN server would cause the IPMI interface to freak out though.
EDIT: Ok something is going on with my IPMI. When I launch IPMIView it shows my pfSense box (192.168.4.10) as active. However when I try to login to it, the login fails and then it goes inactive. Then I have to discover it again and when I do that, it's discovering it with an IP address of 192.168.4.255 which doesn't make sense since that's the broadcast address. However once it discovers the IPMI device at that IP address and I login to it, the original IPMI device (192.168.4.10) becomes active again and I can only access that IP address and no longer the 192.168.4.255 device.
I have a bunch of SM boards with IPMI on them and I've never had them act this way. However I'm wondering if it has something to do with the fact that the board on which the IPMI is acting as the router/switch by which is communicates.
-
The thing is is OpenVPN doesn't behave as you're describing so it's something else.
-
The thing is is OpenVPN doesn't behave as you're describing so it's something else.
See my edit above, something doesn't seem right with my IPMI. Will try unplugging it when I get home tonight and testing the OpenVPN server again to see if that's the culprit.
-
A dedicated IPMI port set to dedicated is usually best. Hope it's that easy.
-
A dedicated IPMI port set to dedicated is usually best. Hope it's that easy.
I'm hoping so too but I'm skeptical. The moment I configure the OpenVPN server and hit save, the web gui becomes inaccessible and then my box becomes unavailable via IPMI until I rediscover it which has it show back up as 192.168.4.255. Seems like something on my pfSense box itself is causing the issue. It's such a new setup and I have so little configured on it I don't know what it could be. I wonder if it's a bug in 2.2.2 though. Maybe I'll try rolling back and see if that helps at all.
-
I'm starting to lean towards this being a bug. I've disabled everything on my firewall (easy to do since it's a new setup) other than my LAN and WAN interface. Unplugged IPMI so it's off the network. Removed any routes/firewall rules/NAT rules I had in place yet it still gives me the same issue the moment I enable OpenVPN server.
I guess the next thing for me to try is rolling back to 2.2.1 and see what happens.
-
Doubt it's a bug. You have something misconfigured somewhere. Maybe get on the console and look at the routing table, etc when you enable the OpenVPN.
-
Doubt it's a bug. You have something misconfigured somewhere. Maybe get on the console and look at the routing table, etc when you enable the OpenVPN.
Here are my routing tables before and after I enable OpenVPN.
Before:
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default L101.NYCMNY-VFTTP- UGS igb0
nsnyny01.verizon.n 0c:c4:7a:33:d6:f4 UHS igb0
nsnwrk01.verizon.n 0c:c4:7a:33:d6:f4 UHS igb0
108.30.70.0 link#1 U igb0
pool-108-30-70-185 link#1 UHS lo0
localhost link#7 UH lo0
192.168.0.0/22 192.168.4.10 UGS igb1
192.168.4.0 link#2 U igb1
pfSense link#2 UHS lo0After:
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default L101.NYCMNY-VFTTP- UGS igb0
10.0.8.1 link#9 UHS lo0
10.0.8.2 link#9 UH ovpns1
nsnyny01.verizon.n 0c:c4:7a:33:d6:f4 UHS igb0
nsnwrk01.verizon.n 0c:c4:7a:33:d6:f4 UHS igb0
108.30.70.0 link#1 U igb0
pool-108-30-70-185 link#1 UHS lo0
localhost link#7 UH lo0
192.168.0.0/22 192.168.4.10 UGS igb1
192.168.4.0 link#2 U igb1
pfSense link#2 UHS lo0
When I turn the OpenVPN server on, the only thing that appears to not be working is the WebGui. I can SSH into the router but just can't access it via browser. The rest of my network appears fine. I will try and connect one of the OpenVPN clients and see if the tunnel is working tomorrow.
-
What is this:
192.168.0.0/22 192.168.4.10 UGS igb1
What is igb1?
That is what you have defined as the remote networks for the OpenVPN server. Why is the same route on a local interface? What is 192.168.4.10?
Please post the output of Diagnostics > Command Prompt netstat -rn -finet to avoid all the name substitution so we can see the real routes.
-
What is this:
192.168.0.0/22 192.168.4.10 UGS igb1
What is igb1?
That is what you have defined as the remote networks for the OpenVPN server. Why is the same route on a local interface? What is 192.168.4.10?
Please post the output of Diagnostics > Command Prompt netstat -rn -finet to avoid all the name substitution so we can see the real routes.
192.168.4.10 is the gateway to my Verizon Actiontec "router" which I converted to an ether net bridge to serve my set top boxes. I thought that could be the culprit but I disabled that route and gateway and it still gave me the same issue.
-
Show me. Your stuff is hosed, bro. OpenVPN just simply doesn't do what you're describing. Get off the assumption that you have found a "bug" and try to find what you have buggered up.
-
Just noticed this:
I rediscover it which has it show back up as 192.168.4.255
.255 is the broadcast address for a /24, not a valid host address as you have noted. Something buggered.
Ok something is going on with my IPMI. When I launch IPMIView it shows my pfSense box (192.168.4.10) as active.
You just said that 192.168.4.10 was some actiontec router, not pfSense. Which is it?
-
I know something is configured wrong on my end, I don't believe it's a bug anymore which was why I changed the title of my thread.
192.168.4.10 is a gateway to my Verizon Actiontec "router" (with a router of 192.168.0.0/22) configured on my pfSense box which has an IP address of 192.168.4.1. 192.168.4.10 WAS the IPMI address but before I had configured that gateway, I forgot I had changed it. Just to clarify:
192.168.4.1: LAN address of pfSense box
192.168.4.10: Gateway address to Actiontec router (old IP for IPMI)
192.168.4.250: Current IPMI addressI realize it looks bad that my old IPMI address and the address for the gateway to my Actiontec are the same but I can assure they are not currently configured to be the same.
To further confirm a that conflict not being the problem I unplugged my IPMI, and removed the 192.168.4.10 gateway along with the 192.168.0.0/22 route for it from pfSense and still have the same issues once I enable OpenVPN.
What would you like me to show display to show that being the case? Remove them again and do another netstat -r?
-
Another set of netstat -rn -finet commands before and after you do whatever with OpenVPN that appears to break stuff would probably be good.
If you can't get at the webGUI you can do it in ssh.
-
Another set of netstat -rn -finet commands before and after you do whatever with OpenVPN that appears to break stuff would probably be good.
If you can't get at the webGUI you can do it in ssh.
Disabled the 192.168.4.10 gateway and 192.168.0.0/22 route. Then ran netstat -rn -finet commands before and after enabling OpenVPN server. Results below:
Before OpenVPN enabled:
Routing tablesInternet:
Destination Gateway Flags Netif Expire
default 108.30.70.1 UGS igb0
68.237.161.12 0c:c4:7a:33:d6:f4 UHS igb0
71.250.0.12 0c:c4:7a:33:d6:f4 UHS igb0
108.30.70.0/24 link#1 U igb0
108.30.70.185 link#1 UHS lo0
127.0.0.1 link#7 UH lo0
192.168.4.0/24 link#2 U igb1
192.168.4.1 link#2 UHS lo0After OpenVPN enabled:
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 108.30.70.1 UGS igb0
10.0.8.1 link#9 UHS lo0
10.0.8.2 link#9 UH ovpns1
68.237.161.12 0c:c4:7a:33:d6:f4 UHS igb0
71.250.0.12 0c:c4:7a:33:d6:f4 UHS igb0
108.30.70.0/24 link#1 U igb0
108.30.70.185 link#1 UHS lo0
127.0.0.1 link#7 UH lo0
192.168.4.0/24 link#2 U igb1
192.168.4.1 link#2 UHS lo0
Looks to me like the only difference is that it adds the 10.0.8.0 interfaces. Don't see why that alone would break the WebGui.