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

      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 rule

      Could this be a result of something i missed in the OpenVPN setup?

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

        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.

        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:

          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.

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

            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.

            ![Screen Shot 2014-11-22 at 12.11.12 PM.png](/public/imported_attachments/1/Screen Shot 2014-11-22 at 12.11.12 PM.png)
            ![Screen Shot 2014-11-22 at 12.11.12 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-22 at 12.11.12 PM.png_thumb)
            ![Screen Shot 2014-11-22 at 12.13.53 PM.png](/public/imported_attachments/1/Screen Shot 2014-11-22 at 12.13.53 PM.png)
            ![Screen Shot 2014-11-22 at 12.13.53 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-22 at 12.13.53 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:

              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

              Status.PNG
              Status.PNG_thumb
              OPT1_Interface.PNG
              OPT1_Interface.PNG_thumb
              NAT.PNG
              NAT.PNG_thumb
              ![FW Rule.PNG](/public/imported_attachments/1/FW Rule.PNG)
              ![FW Rule.PNG_thumb](/public/imported_attachments/1/FW Rule.PNG_thumb)

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

                Why are you posting a NAT port forward?  You want an entry in outbound NAT.

                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:

                  Why are you posting a NAT port forward?  You want an entry in outbound NAT.

                  That rule is in Outbound, check the attached.

                  NAT2.PNG
                  NAT2.PNG_thumb

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

                    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.

                    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:

                      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 655697

                      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.

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

                        @lastb0isct:

                        @Derelict:

                        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 655697

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

                        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:

                          @lastb0isct:

                          @Derelict:

                          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 655697

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

                          The 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_2

                          When 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 ms

                          It 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 Gateway

                          I think that might be normal behavior, just wanted to point it out.

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

                            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.

                            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:

                              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
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.