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

    OpenVPN traffic blocked by rule

    Scheduled Pinned Locked Moved OpenVPN
    19 Posts 5 Posters 12.7k 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
      LostInIgnorance
      last edited by

      Post your OpenVPN config.  I have a feeling one of those and/or your nat isn't set up correctly.

      1 Reply Last reply Reply Quote 0
      • P
        PhilR
        last edited by

        OpenVPN config screenshot attached - not sure how to export the config (or even if it can be done.)

        Really appreciate your help.

        pfsense_openvpn.jpg
        pfsense_openvpn.jpg_thumb

        1 Reply Last reply Reply Quote 0
        • W
          wjs
          last edited by

          I just opened and then deleted a similar thread(when i saw this one). I'm unable to connect to clients on my lan from my road warrior VPN. I can access the webconfig just fine though.

          I am running 2.0-RC3 (i386) built on Wed Jun 22 00:50:29 EDT 2011

          1 Reply Last reply Reply Quote 0
          • N
            Nachtfalke
            last edited by

            Is it correct with the subnet mask of 255.255.254.0 in you "push route"command ?

            could you connect to clients connected to the "Local Subnet" with 192.168.70.0/24 ?
            Or is it just a problem with the destination subnet 192.168.10.0/23 (remember subnet hint above)?

            1 Reply Last reply Reply Quote 0
            • P
              PhilR
              last edited by

              The push route is correct, it is 192.168.10.0/23. That's at the other end of a site-to-site.

              The problem I'm experiencing is connecting to machines on the local 192.168.70.0/24 network.

              The route table on the client is correctly populating - 192.168.70.0/24 and 192.168.10.0/23 are both routed along the openvpn connection.

              wjs - thanks for that info; I was pondering wether upgrading would fix it. Clearly not.

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                VPN looks fine, it works fine in general and I doubt wjs's issue is the same cause. You still have blocks showing in your firewall log? If so, post /tmp/rules.debug

                1 Reply Last reply Reply Quote 0
                • P
                  PhilR
                  last edited by

                  Here's the vaguely anonymized rules.debug.

                  
#System aliases

loopback = "{ lo0 }"
WAN = "{ re1 }"
LAN = "{ re0 }"
IPsec = "{ enc0 }"
OpenVPN = "{ openvpn }"

#SSH Lockout Table
table <sshlockout> persist
table <webconfiguratorlockout> persist
#pfSnortSam tables
table <snort2c>
table <pfsnortsamout>
table <pfsnortsamin>

table <virusprot>

# User Aliases 

# Gateways
GWWANGW = " route-to ( re1 192.168.6.254 ) "

set loginterface re0
set optimization normal
set limit states 47000
set limit src-nodes 47000

set skip on pfsync0

scrub in on $WAN all    fragment reassemble
scrub in on $LAN all    fragment reassemble

nat-anchor "natearly/*"
nat-anchor "natrules/*"

# Outbound NAT rules

# Subnets to NAT 
tonatsubnets	= "{ 192.168.70.0/24 192.168.71.0/24 127.0.0.0/8  }"
nat on $WAN  from $tonatsubnets port 500 to any port 500 -> 192.168.6.1/32 port 500  
nat on $WAN  from $tonatsubnets to any -> 192.168.6.1/32 port 1024:65535  

# Load balancing anchor
rdr-anchor "relayd/*"
# TFTP proxy
rdr-anchor "tftp-proxy/*"
table <vpns> { 192.168.10.0/23 192.168.0.0/24 }
table <direct_networks> { 192.168.6.0/24 192.168.70.0/24 }
# NAT Inbound Redirects
rdr on re1 proto tcp from 213.246.151.242 to 192.168.6.1 port 22 -> 192.168.70.2
rdr on re1 proto tcp from any to 192.168.6.1 port 443 -> 192.168.70.2
rdr on re1 proto tcp from any to 192.168.6.1 port 993 -> 192.168.70.2
rdr on re1 proto tcp from any to 192.168.6.1 port 39993 -> 192.168.70.2
rdr on re1 proto tcp from any to 192.168.6.1 port 25 -> 192.168.70.2
# UPnPd rdr anchor
rdr-anchor "miniupnpd"

anchor "relayd/*"
#---------------------------------------------------------------------------
# default deny rules
#---------------------------------------------------------------------------
block in log all label "Default deny rule"
block out log all label "Default deny rule"

# We use the mighty pf, we cannot be fooled.
block quick proto { tcp, udp } from any port = 0 to any
block quick proto { tcp, udp } from any to any port = 0

# Block all IPv6
block in quick inet6 all
block out quick inet6 all

# pfSnortSam
block quick from <snort2c> to any label "Block snort2c hosts"
block quick from any to <snort2c> label "Block snort2c hosts"
block quick from <pfsnortsamout> to any label "Block pfSnortSamOut hosts"
block quick from any to <pfsnortsamin> label "Block pfSnortSamIn hosts"

# SSH lockout
block in log quick proto tcp from <sshlockout> to any port 22 label "sshlockout"

# webConfigurator lockout
block in log quick proto tcp from <webconfiguratorlockout> to any port 443 label "webConfiguratorlockout"
block in quick from <virusprot> to any label "virusprot overload table"
table <bogons> persist file "/etc/bogons"
# block bogon networks
# http://www.cymru.com/Documents/bogon-bn-nonagg.txt
block in log quick on $WAN from <bogons> to any label "block bogon networks from WAN"
antispoof for re1
antispoof for re0
# allow access to DHCP server on LAN
pass in on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server"
pass in on $LAN proto udp from any port = 68 to 192.168.70.254 port = 67 label "allow access to DHCP server"
pass out on $LAN proto udp from 192.168.70.254 port = 67 to any port = 68 label "allow access to DHCP server"

# loopback
pass in on $loopback all label "pass loopback"
pass out on $loopback all label "pass loopback"
# let out anything from the firewall host itself and decrypted IPsec traffic
pass out all keep state allow-opts label "let out anything from firewall host itself"
pass out route-to ( re1 192.168.6.254 ) from 192.168.6.1 to !192.168.6.0/24 keep state allow-opts label "let out anything from firewall host itself"
pass out on $IPsec all keep state label "IPsec internal host to host"
# make sure the user cannot lock himself out of the webConfigurator or SSH
pass in quick on re0 proto tcp from any to (re0) port { 80 443  22 } keep state label "anti-lockout rule"

# User-defined rules follow
pass  in  quick  on $WAN reply-to ( re1 192.168.6.254 )  proto { tcp udp }  from any to any port 1194  keep state  label "USER_RULE: OpenVPN"
pass  in  quick  on $WAN reply-to ( re1 192.168.6.254 )  inet proto icmp  from any to 192.168.6.1 icmp-type echoreq keep state  label "USER_RULE: Allow ping"
pass   in  quick  on $WAN reply-to ( re1 192.168.6.254 )  proto tcp  from   213.xxx.yyy.zzz to   192.168.70.2 port 22   label "USER_RULE: NAT Inbound SSH (work)"
pass   in  quick  on $WAN reply-to ( re1 192.168.6.254 )  proto tcp  from any to   192.168.70.2 port 443   label "USER_RULE: NAT Inbound HTTPS"
pass   in  quick  on $WAN reply-to ( re1 192.168.6.254 )  proto tcp  from any to   192.168.70.2 port 993   label "USER_RULE: NAT Inbound IMAPS"
pass   in  quick  on $WAN reply-to ( re1 192.168.6.254 )  proto tcp  from any to   192.168.70.2 port 39993   label "USER_RULE: NAT Inbound SSH"
pass   in  quick  on $WAN reply-to ( re1 192.168.6.254 )  proto tcp  from any to   192.168.70.2 port 25   label "USER_RULE: NAT Inbound SMTP"
pass  in  quick  on $LAN  from 192.168.70.0/24 to any keep state  label "USER_RULE: Default allow LAN to any rule"
pass  in  quick  on $IPsec  proto tcp  from   192.168.0.2 to   192.168.70.2 port 22  flags S/SA keep state  label "USER_RULE: SSH from church"
pass  in  quick  on $IPsec  proto tcp  from   192.168.0.2 to   192.168.70.2 port 25  flags S/SA keep state  label "USER_RULE: SMTP from church"
pass  in  quick  on $IPsec  inet proto icmp  from   192.168.0.2 to 192.168.70.0/24 keep state  label "USER_RULE: SMTP from church"
pass  in  quick  on $IPsec  from   192.168.10.0/23 to   192.168.70.0/23 keep state  label "USER_RULE: Dave"
pass  in  quick  on $OpenVPN  from any to any keep state  label "USER_RULE"

# VPN Rules
pass out on $WAN  route-to ( re1 192.168.6.254 )  proto udp from any to 81.xxx.yyy.xxx port = 500 keep state label "IPsec: Dave - outbound isakmp"
pass in on $WAN  reply-to ( re1 192.168.6.254 )  proto udp from 81.xxx.yyy.xxx to any port = 500 keep state label "IPsec: Dave - inbound isakmp"
pass out on $WAN  route-to ( re1 192.168.6.254 )  proto udp from any to 81.xxx.yyy.xxx port = 4500 keep state label "IPsec: Dave - outbound nat-t"
pass in on $WAN  reply-to ( re1 192.168.6.254 )  proto udp from 81.xxx.yyy.xxx to any port = 4500 keep state label "IPsec: Dave - inbound nat-t"
pass out on $WAN  route-to ( re1 192.168.6.254 )  proto esp from any to 81.xxx.yyy.xxx keep state label "IPsec: Dave - outbound esp proto"
pass in on $WAN  reply-to ( re1 192.168.6.254 )  proto esp from 81.xxx.yyy.xxx to any keep state label "IPsec: Dave - inbound esp proto"
# ERROR! Unable to determine remote IPsec peer address for site.somedomain.com
anchor "tftp-proxy/*"</bogons></bogons></virusprot></webconfiguratorlockout></sshlockout></pfsnortsamin></pfsnortsamout></snort2c></snort2c></direct_networks></vpns></virusprot></pfsnortsamin></pfsnortsamout></snort2c></webconfiguratorlockout></sshlockout>
                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    Rules are correct. What does the output of 'ifconfig -g openvpn' show?

                    1 Reply Last reply Reply Quote 0
                    • P
                      PhilR
                      last edited by

                      Hi cmb - ifconfig -g openvpn results in

                      ovpns1

                      Not much really. Hope that's more useful than it looks!

                      1 Reply Last reply Reply Quote 0
                      • C
                        cmb
                        last edited by

                        that just validates the server's interface is correctly in the 'openvpn' group, which means the rules apply to it correctly, assuming that is the associated interface and you have one OpenVPN server on that host.

                        1 Reply Last reply Reply Quote 0
                        • P
                          PhilR
                          last edited by

                          Yes - there's only one openvpn server on the box.

                          1 Reply Last reply Reply Quote 0
                          • P
                            PhilR
                            last edited by

                            It appears that the update

                            "2.0-RC3 (amd64)
                            built on Wed Jun 29 18:35:57 EDT 2011 "

                            fixed the issue. Very odd.

                            Thanks for the input, guys.

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