Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN Gateway Not "UP"

    Scheduled Pinned Locked Moved OpenVPN
    35 Posts 3 Posters 4.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      lastb0isct
      last edited by

      @Derelict:

      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.

      ![FW Rule2.PNG_thumb](/public/imported_attachments/1/FW Rule2.PNG_thumb)
      ![FW Rule2.PNG](/public/imported_attachments/1/FW Rule2.PNG)

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        Don't know.  Clear states.  Reboot.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • L
          lastb0isct
          last edited by

          @Derelict:

          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

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            You should do basic layer 2/3 troubleshooting and find out where the fault is.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • L
              lastb0isct
              last edited by

              @Derelict:

              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:ESTABLISHED

              I thought all traffic was supposed to go out via UDP, looks like its mostly using TCP for this stuff….

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                No.  You need to do simple ethernet/IP troubleshooting to find out what's broken and where.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • L
                  lastb0isct
                  last edited by

                  @Derelict:

                  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...

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    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.

                    ![Screen Shot 2014-11-23 at 1.44.37 PM.png](/public/imported_attachments/1/Screen Shot 2014-11-23 at 1.44.37 PM.png)
                    ![Screen Shot 2014-11-23 at 1.44.37 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-23 at 1.44.37 PM.png_thumb)

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    1 Reply Last reply Reply Quote 0
                    • L
                      lastb0isct
                      last edited by

                      @Derelict:

                      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:PA

                      Shouldn'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 Completed

                      Are 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
                      1 Reply Last reply Reply Quote 0
                      • L
                        lastb0isct
                        last edited by

                        On the dashboard i'm also seeing activity going to the OPT1 Interface…

                        Dashboard.PNG
                        Dashboard.PNG_thumb

                        1 Reply Last reply Reply Quote 0
                        • L
                          lastb0isct
                          last edited by

                          Any ideas?!

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by

                            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.

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            1 Reply Last reply Reply Quote 0
                            • L
                              lastb0isct
                              last edited by

                              @Derelict:

                              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.

                              1 Reply Last reply Reply Quote 0
                              • DerelictD
                                Derelict LAYER 8 Netgate
                                last edited by

                                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

                                Chattanooga, Tennessee, USA
                                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                1 Reply Last reply Reply Quote 0
                                • L
                                  lastb0isct
                                  last edited by

                                  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!

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.