OpenVPN Gateway Not "UP"
-
Having issues with getting my VPN working. Here is the error i'm seeing in the System Logs for Gateways:
Nov 15 12:38:38 apinger: SIGHUP received, reloading configuration. Nov 15 12:38:48 apinger: ALARM: OPT1_VPNV4(10.146.1.5) *** down *** Nov 15 12:40:12 apinger: SIGHUP received, reloading configuration. Nov 15 12:40:12 apinger: alarm canceled (config reload): OPT1_VPNV4(10.146.1.5) *** down *** Nov 15 12:40:22 apinger: ALARM: OPT1_VPNV4(10.111.1.5) *** down *** Nov 15 12:54:17 apinger: SIGHUP received, reloading configuration. Nov 15 12:54:17 apinger: alarm canceled (config reload): OPT1_VPNV4(10.111.1.5) *** down *** Nov 15 12:54:27 apinger: ALARM: OPT1_VPNV4(10.177.1.5) *** down *** Nov 15 13:01:08 apinger: SIGHUP received, reloading configuration. Nov 15 13:01:08 apinger: alarm canceled (config reload): OPT1_VPNV4(10.177.1.5) *** down *** Nov 15 13:01:18 apinger: ALARM: OPT1_VPNV4(10.175.1.9) *** down ***But, when checking the OpenVPN status i am greeted with this:
PIA OpenVPN UDP up Sun Nov 16 8:18:03 2014 10.117.1.10 198.23.103.68Here is the log from OpenVPN as well:
Nov 16 08:01:53 openvpn[80721]: Initialization Sequence Completed Nov 16 08:04:23 openvpn[80721]: event_wait : Interrupted system call (code=4) Nov 16 08:04:23 openvpn[80721]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1542 10.129.1.6 10.129.1.5 init Nov 16 08:04:23 openvpn[80721]: SIGTERM[hard,] received, process exiting Nov 16 08:04:24 openvpn[41960]: OpenVPN 2.3.3 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 15 2014 Nov 16 08:04:24 openvpn[41960]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Nov 16 08:04:24 openvpn[41960]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Nov 16 08:04:24 openvpn[42222]: UDPv4 link local (bound): [AF_INET]104.172.13.57 Nov 16 08:04:24 openvpn[42222]: UDPv4 link remote: [AF_INET]50.23.113.206:1194 Nov 16 08:04:24 openvpn[42222]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Nov 16 08:04:24 openvpn[42222]: [Private Internet Access] Peer Connection Initiated with [AF_INET]50.23.113.206:1194 Nov 16 08:04:26 openvpn[42222]: TUN/TAP device ovpnc1 exists previously, keep at program end Nov 16 08:04:26 openvpn[42222]: TUN/TAP device /dev/tun1 opened Nov 16 08:04:26 openvpn[42222]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Nov 16 08:04:26 openvpn[42222]: /sbin/ifconfig ovpnc1 10.105.1.6 10.105.1.5 mtu 1500 netmask 255.255.255.255 up Nov 16 08:04:26 openvpn[42222]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1542 10.105.1.6 10.105.1.5 init Nov 16 08:04:26 openvpn[42222]: Initialization Sequence Completed Nov 16 08:04:30 openvpn[42222]: event_wait : Interrupted system call (code=4) Nov 16 08:04:30 openvpn[42222]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1542 10.105.1.6 10.105.1.5 init Nov 16 08:04:30 openvpn[42222]: SIGTERM[hard,] received, process exiting Nov 16 08:04:31 openvpn[69358]: OpenVPN 2.3.3 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 15 2014 Nov 16 08:04:31 openvpn[69358]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Nov 16 08:04:31 openvpn[69358]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Nov 16 08:04:31 openvpn[69537]: UDPv4 link local (bound): [AF_INET]104.172.13.57 Nov 16 08:04:31 openvpn[69537]: UDPv4 link remote: [AF_INET]50.23.115.87:1194 Nov 16 08:04:31 openvpn[69537]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Nov 16 08:04:31 openvpn[69537]: [Private Internet Access] Peer Connection Initiated with [AF_INET]50.23.115.87:1194 Nov 16 08:04:33 openvpn[69537]: TUN/TAP device ovpnc1 exists previously, keep at program end Nov 16 08:04:33 openvpn[69537]: TUN/TAP device /dev/tun1 opened Nov 16 08:04:33 openvpn[69537]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Nov 16 08:04:33 openvpn[69537]: /sbin/ifconfig ovpnc1 10.109.1.6 10.109.1.5 mtu 1500 netmask 255.255.255.255 up Nov 16 08:04:33 openvpn[69537]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1542 10.109.1.6 10.109.1.5 init Nov 16 08:04:33 openvpn[69537]: Initialization Sequence Completed Nov 16 08:13:46 openvpn[69537]: event_wait : Interrupted system call (code=4) Nov 16 08:13:46 openvpn[69537]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1542 10.109.1.6 10.109.1.5 init Nov 16 08:13:46 openvpn[69537]: SIGTERM[hard,] received, process exiting Nov 16 08:18:00 openvpn[31287]: OpenVPN 2.3.3 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 15 2014 Nov 16 08:18:00 openvpn[31287]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Nov 16 08:18:00 openvpn[31287]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Nov 16 08:18:00 openvpn[32085]: UDPv4 link local (bound): [AF_INET]104.172.13.57 Nov 16 08:18:00 openvpn[32085]: UDPv4 link remote: [AF_INET]198.23.103.68:1194 Nov 16 08:18:00 openvpn[32085]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Nov 16 08:18:01 openvpn[32085]: [Private Internet Access] Peer Connection Initiated with [AF_INET]198.23.103.68:1194 Nov 16 08:18:03 openvpn[32085]: TUN/TAP device ovpnc1 exists previously, keep at program end Nov 16 08:18:03 openvpn[32085]: TUN/TAP device /dev/tun1 opened Nov 16 08:18:03 openvpn[32085]: ioctl(TUNSIFMODE): Device busy: Device busy (errno=16) Nov 16 08:18:03 openvpn[32085]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Nov 16 08:18:03 openvpn[32085]: /sbin/ifconfig ovpnc1 10.117.1.10 10.117.1.9 mtu 1500 netmask 255.255.255.255 up Nov 16 08:18:03 openvpn[32085]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1542 10.117.1.10 10.117.1.9 init Nov 16 08:18:03 openvpn[32085]: Initialization Sequence CompletedPlease help!!!
-
Bump…
-
Anyone?!
-
No one has experienced this before or has any insight?!
-
I don't think remote OpenVPN interfaces are pingable. I think the reason is they are actually serviced by the OpenVPN process so there's not a full stack (including ICMP) bound to them. Something like that.
You can change the monitor IP to something at the remote site that will respond to ping.
-
Use a monitor IP that'll actually reply to pings (System>Routing, edit the gateway), the gateway IP of an OpenVPN connection from a provider possibly won't reply to pings.
-
Part of the reason nobody responded is because it takes time and it gets pretty tedious answering the same questions over and over again when things like this exist:
https://doc.pfsense.org/index.php/Why_can't_I_ping_some_OpenVPN_adapter_addresses
Not bagging on you personally, just putting it out there.
-
And, FWIW, if you really want to ping the tunnel address on a site-to-site, just set the tunnel network on the server to a /30 then push an ifconfig to the client:
Tunnel Network: 10.26.254.0/30 (Server will use first address).
In the server's advanced config:
push "ifconfig 10.26.254.2 10.26.254.1";
I tried to do it in the client specific overrides but I couldn't get it to take. I might have something screwed up with the CN or something and it's not matching. Seems like it should work in either place.
This also worked specifying the /30 on both server and client as the tunnel network but I like to keep as much config centralized as I can.
-
Thanks for your responses. I should have been more clear in my original post, so i didn't waste any of your time.
The Gateway does show down all the time, due to the pinging you both were talking about. I don't mind that, if it should still work in that state though i will look into your suggestions.
The real issue i'm facing is that when i turn on the OpenVPN i'm not getting internet access via any of my machines. I followed several guides to set up rules to route specific traffic through the VPN which hasn't worked. In fact when OpenVPN is turned on ALL of my machines behind pfsense lose internet connectivity. I've set a rule that resolves all of the other traffic, but it still looks like anything routed through the OPT1_VPNV4 Gateway has issues. The rule seems fine to me. Below are the rules in place:
IPv4 * 192.168.1.62 * * * OPT1_VPNV4 none PIA_VPN_Rule IPv6 * LAN net * * * * none Default allow LAN IPv6 to any rule IPv4 * LAN net * * * GW_WAN none Default allow LAN to any ruleCould this be a result of something i missed in the OpenVPN setup?
-
That has nothing to do with the GW being down.
Your rules are wrong. The VPN is probably pushing you a default route (Most VPN providers do this, pfSense does it if you check "Redirect gateway" in the server config.) The way to stop it is by using route-nopull; in the PIA client config. You will then have to policy route the desired traffic to PIA.
You'll need to post specifics. Both of your config and the desired behavior.
-
That has nothing to do with the GW being down.
Your rules are wrong. The VPN is probably pushing you a default route (Most VPN providers do this, pfSense does it if you check "Redirect gateway" in the server config.) The way to stop it is by using route-nopull; in the PIA client config. You will then have to policy route the desired traffic to PIA.
You'll need to post specifics. Both of your config and the desired behavior.
I did try to do the route-nopull that was mentioned in another post that you were helping in. Do you know what the rule would have to be for it to work with the route-nopull?
I followed all of the instructions that are posted in this post: https://forum.pfsense.org/index.php?topic=72902.msg397636#msg397636
I am looking to do what that post was out to do, route all traffic from 192.168.1.62 to the VPN, but ALL other traffic goes through the WAN.
-
You need to get the tunnel working and add route-nopull;
You need a firewall rule on LAN with a source address of 192.168.1.62 destination any with gateway set to the VPN.
You need manual outbound NAT that matches 192.168.1.62 on your VPN interface.
That's pretty much it.
Reference the diagram in the footer and the attached firewall rule and NAT entry from pfSense A.
-
You need to get the tunnel working and add route-nopull;
You need a firewall rule on LAN with a source address of 192.168.1.62 destination any with gateway set to the VPN.
You need manual outbound NAT that matches 192.168.1.62 on your VPN interface.
That's pretty much it.
Reference the diagram in the footer and the attached firewall rule and NAT entry from pfSense A.
Thanks for taking the time to help me out Derelict.
I have tried those rules as well as other similar ones and still haven't been able to get my connection out via the VPN. Just testing right now I applied the FW rule on LAN w my source IP and gateway set to the OPT1_VPNV4 and added the NAT rule. I am still getting the External WAN IP. Attaching more screenshots of my settings
-
Why are you posting a NAT port forward? You want an entry in outbound NAT.
-
Why are you posting a NAT port forward? You want an entry in outbound NAT.
That rule is in Outbound, check the attached.
-
Then it should be working. Are you sure the tunnel is up and can pass traffic?
ETA: And please delete or disable that OPT1 port forward rule.
-
Then it should be working. Are you sure the tunnel is up and can pass traffic?
ETA: And please delete or disable that OPT1 port forward rule.
How can i verify that the tunnel is up and passing traffic? In Status –> OpenVPN i get this:
Name ▾ Status Connected Since Virtual Addr Remote Host Bytes Sent Bytes Rcvd
PIA OpenVPN UDP up Sat Nov 22 12:29:20 2014 10.135.1.6 198.23.103.66 1150724 655697I don't see a port forward rule for anything, which rule are you referencing to? I only posted two rules:
Firewall Rules and NAT Outbound.
-
Then it should be working. Are you sure the tunnel is up and can pass traffic?
ETA: And please delete or disable that OPT1 port forward rule.
How can i verify that the tunnel is up and passing traffic? In Status –> OpenVPN i get this:
Name ▾ Status Connected Since Virtual Addr Remote Host Bytes Sent Bytes Rcvd
PIA OpenVPN UDP up Sat Nov 22 12:29:20 2014 10.135.1.6 198.23.103.66 1150724 655697Sure looks like it's up. It should be working. When you try to go to a site using host 192.168.1.62 what happens? If you are trying to connect to something using host 192.168.1.62 and you look at diagnostics->States and filter on 192.168.1.62 what do you see?
If you use diagnostics->ping to host 8.8.8.8 IPv4 Source Address: OPT1 what happens?
I don't see a port forward rule for anything, which rule are you referencing to? I only posted two rules:
Firewall Rules and NAT Outbound.
Yeah. Sorry. I was confused. Nevermind.
-
Then it should be working. Are you sure the tunnel is up and can pass traffic?
ETA: And please delete or disable that OPT1 port forward rule.
How can i verify that the tunnel is up and passing traffic? In Status –> OpenVPN i get this:
Name ▾ Status Connected Since Virtual Addr Remote Host Bytes Sent Bytes Rcvd
PIA OpenVPN UDP up Sat Nov 22 12:29:20 2014 10.135.1.6 198.23.103.66 1150724 655697Sure looks like it's up. It should be working. When you try to go to a site using host 192.168.1.62 what happens? If you are trying to connect to something using host 192.168.1.62 and you look at diagnostics->States and filter on 192.168.1.62 what do you see?
If you use diagnostics->ping to host 8.8.8.8 IPv4 Source Address: OPT1 what happens?
I don't see a port forward rule for anything, which rule are you referencing to? I only posted two rules:
Firewall Rules and NAT Outbound.
Yeah. Sorry. I was confused. Nevermind.
My 192.168.1.62 machine still just goes straight to the internet through the WAN IP, thats what i see from that box. It's a standalone linux box, so I can't really hit a website, but when i do the following here is the output:
lastb0isct@miniserver:~$ curl http://ipecho.net/plain; echo 104.172.13.57The OpenVPN IP is displayed on the main page and that is not the IP listed there.
Here's what i see in the Show States area:tcp 109.201.152.249:1080 <- 192.168.1.62:40313 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:40313 -> 104.172.13.57:48640 -> 109.201.152.249:1080 ESTABLISHED:ESTABLISHED tcp 127.0.0.1:3128 <- 146.255.36.1:80 <- 192.168.1.62:44660 FIN_WAIT_2:FIN_WAIT_2When doing the ping from diagnostics page:
PING 8.8.8.8 (8.8.8.8) from 10.135.1.6: 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=47 time=50.542 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=41.516 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=41.277 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 41.277/44.445/50.542/4.312 msIt makes it through. I do notice that the Pin gis coming from 10.135.1.6, but in the Gateways page the IP of the OPT1 device is 10.135.1.5:
OPT1_VPNV4 OPT1 10.135.1.5 10.135.1.5 Interface OPT1_VPNV4 GatewayI think that might be normal behavior, just wanted to point it out.
-
Yeah. ping reports from as the source address, which is your end of the tunnel. 10.135.1.6 is expected.
See that FW Rules.png screenshot in https://forum.pfsense.org/index.php?topic=84189.msg463104#msg463104
how about a full screenshot. I know it sucks but this should be working and there must be another rule catching the traffic before the VPN rule.
-
Yeah. ping reports from as the source address, which is your end of the tunnel. 10.135.1.6 is expected.
See that FW Rules.png screenshot in https://forum.pfsense.org/index.php?topic=84189.msg463104#msg463104
how about a full screenshot. I know it sucks but this should be working and there must be another rule catching the traffic before the VPN rule.
Thanks for the help!! Screenshot is attached.
-
Don't know. Clear states. Reboot.
-
Don't know. Clear states. Reboot.
At least i know i wasn't going crazy…neither of those worked. Any other ideas or should i try and start over with everything
-
You should do basic layer 2/3 troubleshooting and find out where the fault is.
-
You should do basic layer 2/3 troubleshooting and find out where the fault is.
I don't have any layer 2/3 switches, only dumb switches and everything connected to this pfsense box. Do i need Layer2 switches to take advantage of the OpenVPN plugin?
Also, i checked states and noticed that everything DOES seem to be going through the OpenVPN IP from that perspective, but the box itself is getting back the WAN IP when i do the curl command to ipecho.net.
Here are the states:
tcp 109.201.154.223:1080 <- 192.168.1.62:42290 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:42290 -> 10.146.1.6:3912 -> 109.201.154.223:1080 ESTABLISHED:ESTABLISHED udp 109.201.154.223:49039 <- 192.168.1.62:59319 MULTIPLE:MULTIPLE udp 192.168.1.62:59319 -> 10.146.1.6:54663 -> 109.201.154.223:49039 MULTIPLE:MULTIPLE tcp 46.166.186.204:1080 <- 192.168.1.62:49457 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:49457 -> 10.146.1.6:22597 -> 46.166.186.204:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:44259 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:44259 -> 10.146.1.6:35253 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.152.24:1080 <- 192.168.1.62:50736 FIN_WAIT_2:FIN_WAIT_2 tcp 192.168.1.62:50736 -> 10.146.1.6:55688 -> 109.201.152.24:1080 FIN_WAIT_2:FIN_WAIT_2 tcp 109.201.154.229:1080 <- 192.168.1.62:44384 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:44384 -> 10.146.1.6:6289 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:44623 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:44623 -> 10.146.1.6:38828 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:44637 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:44637 -> 10.146.1.6:7750 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:44957 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:44957 -> 10.146.1.6:31889 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:45094 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:45094 -> 10.146.1.6:30734 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:45163 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:45163 -> 10.146.1.6:13505 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:45412 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:45412 -> 10.146.1.6:5074 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHED tcp 109.201.154.229:1080 <- 192.168.1.62:45492 ESTABLISHED:ESTABLISHED tcp 192.168.1.62:45492 -> 10.146.1.6:23496 -> 109.201.154.229:1080 ESTABLISHED:ESTABLISHEDI thought all traffic was supposed to go out via UDP, looks like its mostly using TCP for this stuff….
-
No. You need to do simple ethernet/IP troubleshooting to find out what's broken and where.
-
No. You need to do simple ethernet/IP troubleshooting to find out what's broken and where.
Updated my previous post…looks like traffic is going through the OPT1 interface via the states page. Just not sure why it's not routing everything directly to the VPN IP...
-
Hmm. Turn off gateway monitoring on OPT1. I don't have to do that on my test system, but yours is still routing out the regular internet.
While we're at it, run this:
Diagnostics->Command Prompt
Execute Shell Command: pfctl -nf /tmp/rules.debug
Does that result in any output? A clean run will look like the attached screenshot.
-
Hmm. Turn off gateway monitoring on OPT1. I don't have to do that on my test system, but yours is still routing out the regular internet.
While we're at it, run this:
Diagnostics->Command Prompt
Execute Shell Command: pfctl -nf /tmp/rules.debug
Does that result in any output? A clean run will look like the attached screenshot.
Yep, the pfctl command is displayed exactly as you show in the screenshot.
It doesn't look like the OPT1 is going through the gateway, judging by the firewall logs:
block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:1745 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.234:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:40083 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.152.236:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:15332 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.212:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:20938 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.152.236:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:40468 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.234:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:59498 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.135.183:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:61156 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.212:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:50930 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.152.236:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:48722 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.212:1080 TCP:PA block Nov 23 13:54:24 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:23884 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.234:1080 TCP:PA block Nov 23 13:54:25 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:12701 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.135.183:1080 TCP:PA block Nov 23 13:54:25 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:14929 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.234:1080 TCP:PA block Nov 23 13:54:25 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:47260 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.234:1080 TCP:PA block Nov 23 13:54:25 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:54284 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.212:1080 TCP:PA block Nov 23 13:54:25 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:34024 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.234:1080 TCP:PA block Nov 23 13:54:26 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:44189 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.152.236:1080 TCP:PA block Nov 23 13:54:26 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:19782 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.132:1080 TCP:PA block Nov 23 13:54:26 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:54814 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.135.183:1080 TCP:PA block Nov 23 13:54:27 Direction=OUT OPT1 Icon Reverse Resolve with DNS Icon Easy Rule: Add to Block List 10.150.1.6:29653 Icon Reverse Resolve with DNS Icon Easy Rule: Pass this traffic 109.201.154.212:1080 TCP:PAShouldn't i be seeing all pass this traffic going to the IP of the OpenVPN IP?
OpenVPN Logs:
Nov 23 13:58:57 openvpn[52945]: event_wait : Interrupted system call (code=4) Nov 23 13:58:57 openvpn[52945]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1542 10.150.1.6 10.150.1.5 init Nov 23 13:58:57 openvpn[52945]: SIGTERM[hard,] received, process exiting Nov 23 13:58:57 openvpn[80678]: OpenVPN 2.3.3 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 15 2014 Nov 23 13:58:57 openvpn[80678]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Nov 23 13:58:57 openvpn[80678]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Nov 23 13:58:58 openvpn[81087]: UDPv4 link local (bound): [AF_INET]104.172.13.57 Nov 23 13:58:58 openvpn[81087]: UDPv4 link remote: [AF_INET]50.97.232.157:1194 Nov 23 13:58:58 openvpn[81087]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Nov 23 13:58:58 openvpn[81087]: [Private Internet Access] Peer Connection Initiated with [AF_INET]50.97.232.157:1194 Nov 23 13:59:00 openvpn[81087]: Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:00 openvpn[81087]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:00 openvpn[81087]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:00 openvpn[81087]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:00 openvpn[81087]: TUN/TAP device ovpnc1 exists previously, keep at program end Nov 23 13:59:00 openvpn[81087]: TUN/TAP device /dev/tun1 opened Nov 23 13:59:00 openvpn[81087]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Nov 23 13:59:00 openvpn[81087]: /sbin/ifconfig ovpnc1 10.111.1.10 10.111.1.9 mtu 1500 netmask 255.255.255.255 up Nov 23 13:59:00 openvpn[81087]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1542 10.111.1.10 10.111.1.9 init Nov 23 13:59:00 openvpn[81087]: Initialization Sequence Completed Nov 23 13:59:02 openvpn[81087]: event_wait : Interrupted system call (code=4) Nov 23 13:59:02 openvpn[81087]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1542 10.111.1.10 10.111.1.9 init Nov 23 13:59:02 openvpn[81087]: SIGTERM[hard,] received, process exiting Nov 23 13:59:07 openvpn[70703]: OpenVPN 2.3.3 amd64-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 15 2014 Nov 23 13:59:07 openvpn[70703]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Nov 23 13:59:07 openvpn[70703]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Nov 23 13:59:07 openvpn[71142]: UDPv4 link local (bound): [AF_INET]104.172.13.57 Nov 23 13:59:07 openvpn[71142]: UDPv4 link remote: [AF_INET]50.97.232.157:1194 Nov 23 13:59:07 openvpn[71142]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Nov 23 13:59:07 openvpn[71142]: [Private Internet Access] Peer Connection Initiated with [AF_INET]50.97.232.157:1194 Nov 23 13:59:10 openvpn[71142]: Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:10 openvpn[71142]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:10 openvpn[71142]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:10 openvpn[71142]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS]) Nov 23 13:59:10 openvpn[71142]: TUN/TAP device ovpnc1 exists previously, keep at program end Nov 23 13:59:10 openvpn[71142]: TUN/TAP device /dev/tun1 opened Nov 23 13:59:10 openvpn[71142]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Nov 23 13:59:10 openvpn[71142]: /sbin/ifconfig ovpnc1 10.198.1.10 10.198.1.9 mtu 1500 netmask 255.255.255.255 up Nov 23 13:59:10 openvpn[71142]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1542 10.198.1.10 10.198.1.9 init Nov 23 13:59:10 openvpn[71142]: Initialization Sequence CompletedAre those dhcp-option and redirect-gateway options going to cause issues?
I just had a "breakthrough", the OPT1 OpenVPN IP was being redirected to 192.168.1.62 for a few seconds! The above OpenVPN logs are from the few seconds that it worked. What other logs can i gather to verify what happened during those few seconds?!
Also, proof from the machine:
curl http://ipecho.net/plain; echo 50.97.232.157
-
On the dashboard i'm also seeing activity going to the OPT1 Interface…
-
Any ideas?!
-
What are all those block rules for? What else have you done?
I'm about ready to ask you to punt, revert to defaults, and bring one system/site up at a time. This stuff pretty much just works unless you do something to break it.
You know what you've done to your router. Nobody else does.
-
What are all those block rules for? What else have you done?
I'm about ready to ask you to punt, revert to defaults, and bring one system/site up at a time. This stuff pretty much just works unless you do something to break it.
You know what you've done to your router. Nobody else does.
Where would i go to delete those rules? I never added anything other than the OpenVPN guide and a couple packages, otherwise this install is brand new.
-
What packages? I don't know where you would go to delete those or what they are. Anyone?
Basic troubleshooting will tell you where the problem is. Not sure what else to tell you.
https://doc.pfsense.org/index.php/Connectivity_Troubleshooting
-
I did a complete reinstall and started fresh. I read a thread around the forums regarding the Traffic Shaper, and i think i might have went in there and tried it out which broke things in the background. After a fresh install and some minor setup hiccups it seems that i'm up and running with OpenVPN routed to the one client that i want!!
Thanks for all the help!
Edit: I believe i found the culprit as well to the issues that i was having this entire time. Squid…after i installed it again it ended up breaking the VPN connection. Had to put in a bypass proxy setting in there and all is well again!
