Something easier than openvpn?

TCM · Sep 14, 2013

Why does $WAN have all those reply-to options? What are they accomplishing in this case? IMHO they are unnecessary.

You don't have any rule for OpenVPN TCP. Your only rule for 10.1.1.15 is UDP.

This YoutubeFix stuff is not effective either. YT doesn't connect to you, you connect to YT. Since you don't redirect anything concerning YT, how could any packet ever match that rule?

Red Squirrel · Sep 15, 2013

Oh that Youtube thing is old, it's disabled. It worked for a bit. There was another rule on the LAN to stop me from being able to connect to it, that's the "return" rule. Was probably not needed but I had added it to be sure. I can actually delete it now, it's no longer in use. Also not sure about $WAN. I never do anything through command line, the rules I posted are the rules I have set. Is there another place I have to put rules too? the VPN is UDP so I only opened up the UDP port, that rule is to connect to the VPN server. 10.1.1.15 is the VPN server, it's port forwarded. There is a static route for it so that VPN traffic can route properly, it does work because ICMP packets work ok.

MrGuvernment · Sep 15, 2013

TCP is better for VPN, at least from all i read.

diizzy · Sep 15, 2013

TCP is never better than UDP for VPN
//Danne

TCM · Sep 15, 2013

MrGuvernment said:
TCP is better for VPN, at least from all i read.

First hit for "TCP-in-TCP": http://sites.inka.de/~W1011/devel/tcp-tcp.html

Unbookmark every site that says otherwise, now.

Grentz · Sep 15, 2013

Just deployed OpenVPN-AS via the VM Appliance in less than 1hr last night. It is dead simple if you know your networking/admin basics.

Red Squirrel · Sep 15, 2013

I know network basics, but I don't know the specifics of how to get the actual openvpn to work, ex: all the cert stuff and what file goes where, what settings to put, what cert data has to be copy and pasted where etc... And it seems all the tutorials I read have different processes so it's hard to figure out which one is actually right. The first one I found was wrong because I kept getting cert errors left and right. Now this other tutorial I found is telling me to create new interfaces, while other tutorials don't etc...

At this point I just want to figure out why pfsense keeps blocking the VPN traffic coming back to the client because I just want to use my old server again given I got it to work years back after lot of hard work. It's the one that's the closest to working. At least it connects, and I can access the VPN server and pfsense. So at this point the issue is at pfsense's end. But like I posted my lan interface blocks nothing, so I don't get why it's hitting the default block rule when there's a rule to allow everything.

Red Squirrel · Sep 15, 2013

Grentz said:
Just deployed OpenVPN-AS via the VM Appliance in less than 1hr last night. It is dead simple if you know your networking/admin basics.

Appliance is key word... the whole thing will already be all setup.

Grentz · Sep 15, 2013

Red Squirrel said:
Appliance is key word... the whole thing will already be all setup.

I know, but saying that it is a good option to get up and going quickly. Plus the OpenVPN-AS version has features the community version does not.

djflow195 · Sep 15, 2013

You say you can connect to pfsense but not beyond, how exactly? Are you pinging the tun IP or another IP on the pfsense router? Do you have a route on the VPN client to get back to the network segment?

IE:

VPN Client IP - 10.255.255.1 / 30
VPN Server IP - 10.255.255.2 / 30
pfsense IP - 192.168.0.1 / 24
Internal Subnet - 192.168.0.0 / 24

You will need a route:

(Windows PC) route add 192.168.0.0 mask 255.255.255.0 10.255.255.2

Are you testing by pinging 192.168.0.1 or 10.255.255.2?

Post the VPN Client log.

Red Squirrel · Sep 15, 2013

If I VPN in I can HTTP/SSH etc to the VPN server (10.1.1.15) which is on the main vlan. I can also HTTPS to the firewall itself. I can't use any TCP protocols on any of my other servers, however, I CAN ping them, so I know the routes are ok. But all TCP traffic is being blocked for some reason.

I disabled iptables on everything just to rule that out, but when I look at the pfsense logs it shows that it's blocking the reply tcp traffic.

So if I try to http to say, server 10.1.1.10 I will see a log entry that it blocked 10.1.1.10:80 from accessing 10.2.1.6:[random client port]. (10.2.1.6 is vpn client)

I recall having this issue before, and I had to uncheck an option somewhere, but it seems to have changed in the new version.

So figured I can get around that limitation by trying to setup OpenVPN in Pfsense itself, but no tutorials seem to work for me, so I gave up on that too. Not really sure what to do anymore. Because of the weird blocking going on in pfsense even if I was to setup some new vpn server I doubt it will work, since the vpn server actually does work right now, it's just pfsense keeps blocking it despite not having a rule to do so.

Edit: found my thread when I had this issue before:

http://hardforum.com/showthread.php?t=1709311&highlight=

The option I had to check is "disable rule checking for static routes under same interface" but pfsense 2 does not seem to have that option.

djflow195 · Sep 15, 2013

These rules should be creating state:

Code:

OpenVPN = "{ openvpn }"

pass in quick on $OpenVPN from any to any keep state label "USER_RULE: Auto added OpenVPN rule from config upgrade."

Can you verify in the state table this is happening?

If you look at your rule dump, there is no pass out quick on VLAN2MAIN, meaning if there is no state, the default 'block out log all label "Default deny rule"' will take effect. As a work around add a manual rule to the VLAN2MAIN interface pass out from 10.1.0.0/16 to 10.2.0.0/16 or whatever the segments are.

Red Squirrel · Sep 15, 2013

djflow195 said:
These rules should be creating state:

Code:

OpenVPN = "{ openvpn }" pass in quick on $OpenVPN from any to any keep state label "USER_RULE: Auto added OpenVPN rule from config upgrade."

Can you verify in the state table this is happening?

If you look at your rule dump, there is no pass out quick on VLAN2MAIN, meaning if there is no state, the default 'block out log all label "Default deny rule"' will take effect. As a work around add a manual rule to the VLAN2MAIN interface pass out from 10.1.0.0/16 to 10.2.0.0/16 or whatever the segments are.

Not sure what you mean. I have a rule for allow * source and dest, shouldn't that cover everything?

Do I need a floating rule or something too? Right now I have nothing in there.

This is what the state table looks like if I filter out the VPN client address, if it helps.

tcp 10.1.1.1:443 <- 10.2.1.6:3293 FIN_WAIT_2:FIN_WAIT_2
tcp 10.1.1.1:443 <- 10.2.1.6:3303 TIME_WAIT:TIME_WAIT
tcp 10.1.1.1:443 <- 10.2.1.6:3304 TIME_WAIT:TIME_WAIT
tcp 10.1.1.1:443 <- 10.2.1.6:3305 TIME_WAIT:TIME_WAIT
udp 10.2.1.6:49251 <- 10.1.1.10:53 NO_TRAFFIC:SINGLE
udp 10.1.1.10:53 -> 10.2.1.6:49251 SINGLE:NO_TRAFFIC
tcp 216.145.16.240:80 <- 10.2.1.6:3306 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3306 -> 192.168.2.100:28107 -> 216.145.16.240:80 FIN_WAIT_2:FIN_WAIT_2
udp 10.2.1.6:61344 <- 10.1.1.10:53 NO_TRAFFIC:SINGLE
udp 10.1.1.10:53 -> 10.2.1.6:61344 SINGLE:NO_TRAFFIC
tcp 8.27.244.253:80 <- 10.2.1.6:3307 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3307 -> 192.168.2.100:38964 -> 8.27.244.253:80 FIN_WAIT_2:FIN_WAIT_2
tcp 74.125.29.95:80 <- 10.2.1.6:3308 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3308 -> 192.168.2.100:61318 -> 74.125.29.95:80 FIN_WAIT_2:FIN_WAIT_2
tcp 8.27.244.253:80 <- 10.2.1.6:3309 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3309 -> 192.168.2.100:36191 -> 8.27.244.253:80 FIN_WAIT_2:FIN_WAIT_2
tcp 8.27.244.253:80 <- 10.2.1.6:3310 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3310 -> 192.168.2.100:36534 -> 8.27.244.253:80 FIN_WAIT_2:FIN_WAIT_2
tcp 8.27.244.253:80 <- 10.2.1.6:3311 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3311 -> 192.168.2.100:34290 -> 8.27.244.253:80 FIN_WAIT_2:FIN_WAIT_2
udp 10.2.1.6:56491 <- 10.1.1.10:53 NO_TRAFFIC:SINGLE
udp 10.1.1.10:53 -> 10.2.1.6:56491 SINGLE:NO_TRAFFIC
tcp 8.27.244.253:80 <- 10.2.1.6:3312 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3312 -> 192.168.2.100:2207 -> 8.27.244.253:80 FIN_WAIT_2:FIN_WAIT_2
tcp 8.27.244.253:80 <- 10.2.1.6:3313 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3313 -> 192.168.2.100:26825 -> 8.27.244.253:80 FIN_WAIT_2:FIN_WAIT_2
tcp 8.27.244.253:80 <- 10.2.1.6:3314 FIN_WAIT_2:FIN_WAIT_2
tcp 10.2.1.6:3314 -> 192.168.2.100:48889 -> 8.27.244.253:80 FIN_WAIT_2:FIN_WAIT_2
tcp 142.166.149.54:80 <- 10.2.1.6:3315 ESTABLISHED:ESTABLISHED
tcp 10.2.1.6:3315 -> 192.168.2.100:10060 -> 142.166.149.54:80 ESTABLISHED:ESTABLISHED
tcp 10.1.1.1:443 <- 10.2.1.6:3316 TIME_WAIT:TIME_WAIT
tcp 10.1.1.1:443 <- 10.2.1.6:3319 ESTABLISHED:ESTABLISHED

Also I forgot to mention DNS does work, not sure if that uses TCP or UDP... I'm starting to think this issue may be specifically TCP traffic. Traffic going out to the internet is also fine, it's just local traffic.

goodcooper · Sep 15, 2013

TCM said:
OpenVPN _is_ dead simple... _if_ you know networks, routing and a bit of certs.

Don't take it personal, but whenever I read your threads I get the feeling you're into all this stuff way ahead of yourself. If it "just sits there", the first thing is to take out tcpdump and look at what packets are making it where. If PFsense is blocking any "reply packets" it must mean you're not even using stateful filtering or somesuch.

The OpenVPN examples, together with the man page, are more than enough to get going. The man page documents all options.

gotta agree here....

it's like "oh yea, it's another Red Squirrel post"

i mean i'm not trying to be mean or anything, but there's a reason we get paid to do IT for folks.... it IS work

"take the time to figure it out and you'll be rewarded" is pretty much my IT motto, and it's how i run my IT dept, and we seem to be pretty successful....

djflow195 · Sep 15, 2013

Now that I look at it further, it looks like this was an upgrade install, have you tried a fresh install? A pain I know, but sometimes the upgrades on pfSense go south. 2.1 has just been released, try a clean install with it.

Here are the ESTABLISHED states:

Code:

tcp 142.166.149.54:80 <- 10.2.1.6:3315 ESTABLISHED:ESTABLISHED
tcp 10.2.1.6:3315 -> 192.168.2.100:10060 -> 142.166.149.54:80 ESTABLISHED:ESTABLISHED
tcp 10.1.1.1:443 <- 10.2.1.6:3319 ESTABLISHED:ESTABLISHED

What you want to look for is an ESTABLISHED link similar to the last line above:

Code:

tcp dst:port <- src:port ESTABLISHED:ESTABLISHED (packet in)
tcp src:port -> dst:port ESTABLISHED:ESTABLISHED (packet out)
tcp src:port -> natip:port -> dst:port ESTABLISHED:ESTABLISHED (packet out, NATed)

Only thing I can think of is that your packets coming in are not creating state, so pfSense drops them with the default rule. But your pass all should take care of that. Something is definitely wonky with your config as I have set this up multiple times with no issues.

Red Squirrel · Sep 15, 2013

I originally upgraded but that failed (well it worked, but the old P3 was just too old to handle the traffic I needed it to) so I ended up clean installing on a new machine. So it's odd that it's showing as being an upgrade as while I did do an upgrade, I eventually just did a clean install on a whole other machine. As a new change to my environment I also added VLANs and in that process I ended up losing most of my rules so I wiped everything and started over.

So what's happening is, there are rules at the very low level of the system that arn't being reflected in the config but still being applied? Is there a way I can wipe all of that?

goodcooper said:
gotta agree here....

it's like "oh yea, it's another Red Squirrel post"

i mean i'm not trying to be mean or anything, but there's a reason we get paid to do IT for folks.... it IS work

"take the time to figure it out and you'll be rewarded" is pretty much my IT motto, and it's how i run my IT dept, and we seem to be pretty successful....

I'm TRYING to figure it out, but this is just all too complicated with very little documentation that covers these type of problems. I've googled this to no end but I don't even know what to look for because it's such a complex problem. I've worked in IT, and sometimes, you do have to get someone else involved to help too, especially with software you did not write yourself.

I've been trying to figure this out for almost a week now, that's why I came for help. If you are just going to diss me for not being the all mighty know it all, then stop posting in my thread.

TCM · Sep 16, 2013

Unless you have a state-policy if-bound, all rules should create floating state. I'm just not sure if that works as intended with the reply-to option.

These firewall logs are also conveniently missing the direction the packet was blocked on.

I would almost recommend dumping any fancy interfaces, installing OpenBSD with _the_ original/best pf and writing your ruleset from scratch. I'm just not quite sure it would be helping. You could give it a try though.

One would think tools like PFsense make stuff easier, but sometimes throwing away all the fluff and doing it raw and simple is more enlightenment than dicking around in a fancy interface.

Red Squirrel · Sep 16, 2013

The direction is shown.

Source: 10.1.1.10 is the server I am trying to connect to. (just an example as this happens to any server I try to connect to and any port, but ping works) 10.2.1.6 is the VPN client (originator). There's 4 blocks but think it's just because the HTTP response is sent in multiple packets as it's probably too big for just one.

The request packet seems to make it through. But when the server tries to reply, that packet is what is getting blocked, at least according to that log. Somehow, the default rule is applying yet as shown in my rule screen shot there is only 2 rules and one of them is allowing everything inbound and outbound for that interface, which is the same one as everything. (you can completely forget the other ones, nothing relevant on there).

I know this is probably some silly setting somewhere, last time I ran into this issue it turned out to be a check box. I've tried all those though and no luck. The specific setting I used last time is not in the latest version. But it might be hidden away and called something else. What about system tunable? Is there something in there? I don't know what any of that stuff is talking about so I have it all default. Sounds like deep system stuff for devs mostly, but maybe there's something I have to do?

I rather not reinstall, the server is fully racked up now and there is no monitor or other way to get console access to it without taking it out, and it's just a pain in the ass. It already is a clean install. Whatever stuff you're seeing in the raw config is generated by pfsense because I did not touch any of the raw system files. I only use the front end.

TCM · Sep 16, 2013

You're right. You can deduce the direction by guessing that 80 is most probably the destination port, but only if you know what interface 10.1.1.10 is living on. If you do tcpdump pflog0, you get the direction spelled out so there's no room for misunderstanding.

There's 4 blocks but think it's just because the HTTP response is sent in multiple packets as it's probably too big for just one.

The TCP:SA tells you this is the second part of the 3-way TCP handshake: 1) SYN 2) SYN-ACK 3) ACK. A SYN-ACK contains no payload. You get 4 packets because after the block, the server is not getting any ACK and is retrying his part of establishing the connection 3 more times.

Please, I really want to get down to this. Post the outputs of

Code:

ifconfig -a
netstat -rn
pfctl -a '*' -vvsr

An interface called pflog0 should exist. Run

Code:

tcpdump -nei pflog0

and then try to establish a connection and post the output.

PS: I just noticed these:

Code:

pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to any port 53  keep state  label "USER_RULE: Internet - dns"
pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to any port 109 >< 996  keep state  label "USER_RULE: Internet - pop3"
pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to any port 142 >< 994  keep state  label "USER_RULE: Internet - imap"
pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to 10.11.11.1 port 53  keep state  label "USER_RULE: Gateway DNS"

The last one is redundant. The POP3 and IMAP rules include a whole range of ports needlessly. And finally, POP3 and IMAP is never UDP.

Red Squirrel · Sep 16, 2013

TCM said:
You're right. You can deduce the direction by guessing that 80 is most probably the destination port, but only if you know what interface 10.1.1.10 is living on. If you do tcpdump pflog0, you get the direction spelled out so there's no room for misunderstanding.

10.1.1.10 is on interface vlan2. Also says bge_0vlan2 in the little popup. That server is plugged into that vlan on the switch which has a trunk uplink to the firewall.

Code:
Please, I really want to get down to this. Post the outputs of

Code:

ifconfig -a netstat -rn pfctl -a '*' -vvsr

Here is the outputs:

ifconfig -a

Code:

$ ifconfig -a
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
	ether 00:1e:8c:ca:9a:27
	inet6 fe80::21e:8cff:feca:9a27%bge0 prefixlen 64 scopeid 0x1 
	nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
	ether 00:1e:8c:ca:9b:53
	inet6 fe80::21e:8cff:feca:9b53%bge1 prefixlen 64 scopeid 0x2 
	inet 192.168.2.100 netmask 0xffffff00 broadcast 192.168.2.255
	nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500
pfsync0: flags=0<> metric 0 mtu 1460
	syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
pflog0: flags=100<PROMISC> metric 0 mtu 33200
enc0: flags=0<> metric 0 mtu 1536
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 
	nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
bge0_vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=3<RXCSUM,TXCSUM>
	ether 00:1e:8c:ca:9a:27
	inet6 fe80::21e:8cff:feca:9a27%bge0_vlan2 prefixlen 64 scopeid 0x8 
	inet 10.1.1.1 netmask 0xffff0000 broadcast 10.1.255.255
	nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 2 parent interface: bge0
bge0_vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=3<RXCSUM,TXCSUM>
	ether 00:1e:8c:ca:9a:27
	inet6 fe80::21e:8cff:feca:9a27%bge0_vlan3 prefixlen 64 scopeid 0x9 
	inet 10.11.10.1 netmask 0xffffff00 broadcast 10.11.10.255
	nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 3 parent interface: bge0
bge0_vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=3<RXCSUM,TXCSUM>
	ether 00:1e:8c:ca:9a:27
	inet6 fe80::21e:8cff:feca:9a27%bge0_vlan4 prefixlen 64 scopeid 0xa 
	inet 10.11.11.1 netmask 0xffffff00 broadcast 10.11.11.255
	nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	vlan: 4 parent interface: bge0
tun2: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
ovpns1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	ether 00:bd:04:53:3c:01
	inet6 fe80::2bd:4ff:fe53:3c01%ovpns1 prefixlen 64 scopeid 0xc 
	nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
	Opened by PID 49268
tun1: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>

netstat -rn

Code:

$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.2.1        UGS         0  1676795   bge1
10.1.0.0/16        link#8             U           0 553553132 bge0_v
10.1.1.1           link#8             UHS         0        0    lo0
10.2.1.0/24        10.1.1.15          UGS         0   420186 bge0_v
10.11.10.0/24      link#9             U           0 380242531 bge0_v
10.11.10.1         link#9             UHS         0        0    lo0
10.11.11.0/24      link#10            U           0        0 bge0_v
10.11.11.1         link#10            UHS         0        0    lo0
127.0.0.1          link#7             UH          0     1325    lo0
192.168.2.0/24     link#2             U           0        0   bge1
192.168.2.1        00:1e:8c:ca:9b:53  UHS         0    22760   bge1
192.168.2.100      link#2             UHS         0        0    lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::1                               ::1                           UH          lo0
fe80::%bge0/64                    link#1                        U          bge0
fe80::21e:8cff:feca:9a27%bge0     link#1                        UHS         lo0
fe80::%bge1/64                    link#2                        U          bge1
fe80::21e:8cff:feca:9b53%bge1     link#2                        UHS         lo0
fe80::%lo0/64                     link#7                        U           lo0
fe80::1%lo0                       link#7                        UHS         lo0
fe80::%bge0_vlan2/64              link#8                        U      bge0_vla
fe80::21e:8cff:feca:9a27%bge0_vlan2 link#8                        UHS         lo0
fe80::%bge0_vlan3/64              link#9                        U      bge0_vla
fe80::21e:8cff:feca:9a27%bge0_vlan3 link#9                        UHS         lo0
fe80::%bge0_vlan4/64              link#10                       U      bge0_vla
fe80::21e:8cff:feca:9a27%bge0_vlan4 link#10                       UHS         lo0
fe80::%ovpns1/64                  link#12                       U        ovpns1
fe80::2bd:4ff:fe53:3c01%ovpns1    link#12                       UHS         lo0
ff01:1::/32                       fe80::21e:8cff:feca:9a27%bge0 U          bge0
ff01:2::/32                       fe80::21e:8cff:feca:9b53%bge1 U          bge1
ff01:7::/32                       ::1                           U           lo0
ff01:8::/32                       fe80::21e:8cff:feca:9a27%bge0_vlan2 U      bge0_vla
ff01:9::/32                       fe80::21e:8cff:feca:9a27%bge0_vlan3 U      bge0_vla
ff01:a::/32                       fe80::21e:8cff:feca:9a27%bge0_vlan4 U      bge0_vla
ff01:c::/32                       fe80::2bd:4ff:fe53:3c01%ovpns1 U        ovpns1
ff02::%bge0/32                    fe80::21e:8cff:feca:9a27%bge0 U          bge0
ff02::%bge1/32                    fe80::21e:8cff:feca:9b53%bge1 U          bge1
ff02::%lo0/32                     ::1                           U           lo0
ff02::%bge0_vlan2/32              fe80::21e:8cff:feca:9a27%bge0_vlan2 U      bge0_vla
ff02::%bge0_vlan3/32              fe80::21e:8cff:feca:9a27%bge0_vlan3 U      bge0_vla
ff02::%bge0_vlan4/32              fe80::21e:8cff:feca:9a27%bge0_vlan4 U      bge0_vla
ff02::%ovpns1/32                  fe80::2bd:4ff:fe53:3c01%ovpns1 U        ovpns1

pfctl -a '*' -vvsr

Code:

$ pfctl -a '*' -vvsr
@0 scrub on bge1 all fragment reassemble
  [ Evaluations: 2699344   Packets: 1337585   Bytes: 64793331    States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@1 scrub on bge0_vlan2 all fragment reassemble
  [ Evaluations: 1361759   Packets: 1279069   Bytes: 61622612    States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@2 scrub on bge0_vlan3 all fragment reassemble
  [ Evaluations: 82690     Packets: 82682     Bytes: 3598714     States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@3 scrub on bge0_vlan4 all fragment reassemble
  [ Evaluations: 8         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@0 anchor "*" all {
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
}
@1 block drop in log all label "Default deny rule"
  [ Evaluations: 204629    Packets: 36053     Bytes: 2787120     States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@2 block drop out log all label "Default deny rule"
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@3 block drop in quick inet6 all
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@4 block drop out quick inet6 all
  [ Evaluations: 84379     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@5 block drop quick proto tcp from any port = 0 to any
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@6 block drop quick proto tcp from any to any port = 0
  [ Evaluations: 144983    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@7 block drop quick proto udp from any port = 0 to any
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@8 block drop quick proto udp from any to any port = 0
  [ Evaluations: 59461     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@9 block drop quick from <snort2c:0> to any label "Block snort2c hosts"
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@10 block drop quick from any to <snort2c:0> label "Block snort2c hosts"
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@11 block drop in log quick proto tcp from <sshlockout:0> to any port = ssh label "sshlockout"
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@12 block drop in log quick proto tcp from <webConfiguratorlockout:0> to any port = https label "webConfiguratorlockout"
  [ Evaluations: 72843     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@13 block drop in quick from <virusprot:0> to any label "virusprot overload table"
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@14 block drop in log quick on bge1 from <bogons:11> to any label "block bogon networks from WAN"
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@15 block drop in on ! bge1 inet from 192.168.2.0/24 to any
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@16 block drop in inet from 192.168.2.100 to any
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@17 block drop in on bge1 inet6 from fe80::21e:8cff:feca:9b53 to any
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@18 pass in on bge1 proto udp from any port = bootps to any port = bootpc keep state label "allow dhcp client out WAN"
  [ Evaluations: 72774     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@19 pass out on bge1 proto udp from any port = bootpc to any port = bootps keep state label "allow dhcp client out WAN"
  [ Evaluations: 119560    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@20 block drop in on ! bge0_vlan2 inet from 10.1.0.0/16 to any
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@21 block drop in inet from 10.1.1.1 to any
  [ Evaluations: 157821    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@22 block drop in on bge0_vlan2 inet6 from fe80::21e:8cff:feca:9a27 to any
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@23 pass in quick on bge0_vlan2 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
  [ Evaluations: 45632     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@24 pass in quick on bge0_vlan2 inet proto udp from any port = bootpc to 10.1.1.1 port = bootps keep state label "allow access to DHCP server"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@25 pass out quick on bge0_vlan2 inet proto udp from 10.1.1.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
  [ Evaluations: 96322     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@26 block drop in on ! bge0_vlan3 inet from 10.11.10.0/24 to any
  [ Evaluations: 204629    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@27 block drop in inet from 10.11.10.1 to any
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@28 block drop in on bge0_vlan3 inet6 from fe80::21e:8cff:feca:9a27 to any
  [ Evaluations: 120250    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@29 pass in quick on bge0_vlan3 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
  [ Evaluations: 1842      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@30 pass in quick on bge0_vlan3 inet proto udp from any port = bootpc to 10.11.10.1 port = bootps keep state label "allow access to DHCP server"
  [ Evaluations: 6         Packets: 12        Bytes: 4344        States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@31 pass out quick on bge0_vlan3 inet proto udp from 10.11.10.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
  [ Evaluations: 84469     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@32 block drop in on ! bge0_vlan4 inet from 10.11.11.0/24 to any
  [ Evaluations: 204623    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@33 block drop in inet from 10.11.11.1 to any
  [ Evaluations: 120244    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@34 block drop in on bge0_vlan4 inet6 from fe80::21e:8cff:feca:9a27 to any
  [ Evaluations: 120244    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@35 pass in quick on bge0_vlan4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@36 pass in quick on bge0_vlan4 inet proto udp from any port = bootpc to 10.11.11.1 port = bootps keep state label "allow access to DHCP server"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@37 pass out quick on bge0_vlan4 inet proto udp from 10.11.11.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
  [ Evaluations: 84379     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@38 pass in on lo0 all flags S/SA keep state label "pass loopback"
  [ Evaluations: 204623    Packets: 4         Bytes: 545         States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@39 pass out on lo0 all flags S/SA keep state label "pass loopback"
  [ Evaluations: 4         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@40 pass out all flags S/SA keep state allow-opts label "let out anything from firewall host itself"
  [ Evaluations: 204621    Packets: 417209    Bytes: 28386834    States: 174   ]
  [ Inserted: uid 0 pid 58208 ]
@41 pass out route-to (bge1 192.168.2.1) inet from 192.168.2.100 to ! 192.168.2.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
  [ Evaluations: 84379     Packets: 195297    Bytes: 31987215    States: 186   ]
  [ Inserted: uid 0 pid 58208 ]
@42 pass in inet all flags S/SA keep state label "NAT REFLECT: Allow traffic to localhost" tagged PFREFLECT
  [ Evaluations: 204623    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@43 anchor "*" all {
  [ Evaluations: 204623    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
}
@44 pass in quick on bge1 reply-to (bge1 192.168.2.1) inet proto tcp from <terraria:3> to 10.1.2.11 port = 7777 flags S/SA keep state label "USER_RULE: NAT Terraria"
  [ Evaluations: 204623    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@45 pass in quick on bge1 reply-to (bge1 192.168.2.1) inet proto udp from <vpn:4> to 10.1.1.15 port = 25025 keep state label "USER_RULE: NAT VPN SRV"
  [ Evaluations: 72774     Packets: 2426      Bytes: 770751      States: 1     ]
  [ Inserted: uid 0 pid 58208 ]
@46 pass in quick on bge1 reply-to (bge1 192.168.2.1) inet proto tcp from <vpn:4> to 10.1.1.3 port = ssh flags S/SA keep state label "USER_RULE: NAT Hal9000 SSH"
  [ Evaluations: 37593     Packets: 606       Bytes: 53857       States: 1     ]
  [ Inserted: uid 0 pid 58208 ]
@47 pass in quick on bge1 reply-to (bge1 192.168.2.1) inet proto tcp from <Envirostate:1> to 10.1.1.3 port = 9000 flags S/SA keep state label "USER_RULE: NAT Envirostate Server"
  [ Evaluations: 72587     Packets: 78259     Bytes: 4515252     States: 4     ]
  [ Inserted: uid 0 pid 58208 ]
@48 pass in quick on bge1 reply-to (bge1 192.168.2.1) inet proto tcp from <terraria:3> to 10.1.1.14 port = 25565 flags S/SA keep state label "USER_RULE: NAT Minecraft"
  [ Evaluations: 36628     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@49 pass in quick on bge1 reply-to (bge1 192.168.2.1) inet proto tcp from any to 10.1.1.22 port 7880 >< 7890 flags S/SA keep state label "USER_RULE: P2P Torrents"
  [ Evaluations: 36628     Packets: 289182    Bytes: 18091750    States: 159   ]
  [ Inserted: uid 0 pid 58208 ]
@50 pass in quick on openvpn all flags S/SA keep state label "USER_RULE: Auto added OpenVPN rule from config upgrade."
  [ Evaluations: 120704    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@51 pass in quick on openvpn all flags S/SA keep state label "USER_RULE: OpenVPN Open VPN 1 wizard"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@52 pass in quick on bge0_vlan2 inet from any to 10.1.1.1 flags S/SA keep state label "USER_RULE: Antilockout rule - do not delete, leave on top"
  [ Evaluations: 120704    Packets: 1666      Bytes: 425503      States: 4     ]
  [ Inserted: uid 0 pid 58208 ]
@53 pass in quick on bge0_vlan2 all flags S/SA keep state label "USER_RULE: Internet"
  [ Evaluations: 45616     Packets: 179965    Bytes: 28456136    States: 187   ]
  [ Inserted: uid 0 pid 58208 ]
@54 pass in quick on bge0_vlan3 inet from any to 10.11.10.1 flags S/SA keep state label "USER_RULE: Antilockout rule - do not delete, leave on top "
  [ Evaluations: 37893     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@55 pass in quick on bge0_vlan3 inet proto tcp from any to 10.1.1.10 port = domain flags S/SA keep state label "USER_RULE: DNS"
  [ Evaluations: 1836      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@56 pass in quick on bge0_vlan3 inet proto udp from any to 10.1.1.10 port = domain keep state label "USER_RULE: DNS"
  [ Evaluations: 90        Packets: 45938     Bytes: 4871475     States: 1     ]
  [ Inserted: uid 0 pid 58208 ]
@57 pass in quick on bge0_vlan3 inet proto tcp from any to 10.1.1.3 port = http flags S/SA keep state label "USER_RULE: Hal9000"
  [ Evaluations: 1810      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@58 pass in quick on bge0_vlan3 inet proto udp from any to 10.1.1.3 port = http keep state label "USER_RULE: Hal9000"
  [ Evaluations: 64        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@59 pass in quick on bge0_vlan3 inet proto tcp from any to 10.1.1.22 port = http flags S/SA keep state label "USER_RULE: p2p web"
  [ Evaluations: 1810      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@60 pass in quick on bge0_vlan3 inet proto tcp from any to 10.1.1.22 port = 9091 flags S/SA keep state label "USER_RULE: p2p web"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@61 pass in quick on bge0_vlan3 inet proto tcp from any to 10.1.2.10 port = 10000 flags S/SA keep state label "USER_RULE: Port 10000, for misc. iperf etc"
  [ Evaluations: 1746      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@62 block drop in quick on bge0_vlan3 from any to <localrange:2> label "USER_RULE: Local range"
  [ Evaluations: 1810      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@63 pass in quick on bge0_vlan3 all flags S/SA keep state label "USER_RULE: Internet"
  [ Evaluations: 1810      Packets: 17925     Bytes: 3961656     States: 8     ]
  [ Inserted: uid 0 pid 58208 ]
@64 block drop in quick on bge0_vlan4 from any to <localrange:2> label "USER_RULE: Deny LAN"
  [ Evaluations: 36057     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@65 pass in quick on bge0_vlan4 proto tcp from any to any port 79 >< 444 flags S/SA keep state label "USER_RULE: Internet - http"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@66 pass in quick on bge0_vlan4 proto tcp from any to any port = domain flags S/SA keep state label "USER_RULE: Internet - dns"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@67 pass in quick on bge0_vlan4 proto udp from any to any port = domain keep state label "USER_RULE: Internet - dns"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@68 pass in quick on bge0_vlan4 proto tcp from any to any port 109 >< 996 flags S/SA keep state label "USER_RULE: Internet - pop3"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@69 pass in quick on bge0_vlan4 proto udp from any to any port 109 >< 996 keep state label "USER_RULE: Internet - pop3"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@70 pass in quick on bge0_vlan4 proto tcp from any to any port 142 >< 994 flags S/SA keep state label "USER_RULE: Internet - imap"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@71 pass in quick on bge0_vlan4 proto udp from any to any port 142 >< 994 keep state label "USER_RULE: Internet - imap"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@72 pass in quick on bge0_vlan4 inet proto tcp from any to 10.11.11.1 port = domain flags S/SA keep state label "USER_RULE: Gateway DNS"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@73 pass in quick on bge0_vlan4 inet proto udp from any to 10.11.11.1 port = domain keep state label "USER_RULE: Gateway DNS"
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
@74 anchor "*" all {
  [ Evaluations: 120434    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 58208 ]
}

Code:
An interface called pflog0 should exist. Run

Code:

tcpdump -nei pflog0

and then try to establish a connection and post the output.

edit: got it... going to assume you wanted a dump of when the packets get blocked? I tried to access 10.1.1.10 and 10.1.1.22.

Code:

02:28:05.674120 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4588: [|tcp]
02:28:05.926511 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4589: [|tcp]
02:28:06.329618 rule 1/0(match): block in on bge1: 117.211.65.122.54219 > 192.168.2.100.10531: UDP, length 103
02:28:06.340561 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4572: [|tcp]
02:28:06.540561 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4571:  tcp 28 [bad hdr length 0 - too short, < 20]
02:28:07.340854 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4573: [|tcp]
02:28:07.596331 rule 1/0(match): block in on bge1: 115.95.98.171.32482 > 192.168.2.100.53705: UDP, length 103
02:28:08.644266 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4588: [|tcp]
02:28:08.846384 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4589: [|tcp]
02:28:08.924526 rule 1/0(match): block in on bge1: 62.198.53.107.47669 > 192.168.2.100.7881: UDP, length 30
02:28:08.963447 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4590: [|tcp]
02:28:09.140516 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4588: [|tcp]
02:28:09.140530 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4589: [|tcp]
02:28:09.214612 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4591: [|tcp]
02:28:09.679538 rule 1/0(match): block in on bge1: 100.2.124.151.36329 > 192.168.2.100.7881: UDP, length 67
02:28:11.964469 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4590: [|tcp]
02:28:12.164680 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4591: [|tcp]
02:28:12.165926 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4590: [|tcp]
02:28:12.366081 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4591: [|tcp]
02:28:12.654352 rule 1/0(match): block in on bge1: 91.124.51.190.54488 > 192.168.2.100.10531: UDP, length 106
02:28:13.704777 rule 1/0(match): block in on bge1: 178.252.80.200.25700 > 192.168.2.100.10531: UDP, length 103
02:28:14.685449 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4588: [|tcp]
02:28:14.881370 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4589: [|tcp]
02:28:15.141469 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4588: [|tcp]
02:28:15.341527 rule 1/0(match): block in on bge0_vlan2: 10.1.1.10.80 > 10.2.1.6.4589: [|tcp]
02:28:17.283266 rule 1/0(match): block in on bge1: 173.35.185.235.28543 > 192.168.2.100.10531: UDP, length 103
02:28:17.898800 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4590: [|tcp]
02:28:18.108726 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4591:  tcp 28 [bad hdr length 0 - too short, < 20]
02:28:18.168629 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4590:  tcp 28 [bad hdr length 0 - too short, < 20]
02:28:18.568736 rule 1/0(match): block in on bge0_vlan2: 10.1.1.22.80 > 10.2.1.6.4591: [|tcp]
^C

PS: I just noticed these:

Code:

pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to any port 53  keep state  label "USER_RULE: Internet - dns"
pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to any port 109 >< 996  keep state  label "USER_RULE: Internet - pop3"
pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to any port 142 >< 994  keep state  label "USER_RULE: Internet - imap"
pass  in  quick  on $VLAN4WIFIPUBLIC  proto { tcp udp }  from any to 10.11.11.1 port 53  keep state  label "USER_RULE: Gateway DNS"

The last one is redundant. The POP3 and IMAP rules include a whole range of ports needlessly. And finally, POP3 and IMAP is never UDP.

VLAN4WIFIPUBLIC is not used for anything right now. Not sure why DNS is there twice or what this imap/pop3 stuff is, I made rules for the ports, never did any ranges. I think when it sees a recognizable port it must do something differently. This has nothing to do with anything though, that vlan is not even setup on the switch. It's there for future as I eventually want to make a separate wifi vlan that is 100% internet only.

Oh and 192.168.2.100 is the WAN interface and can be treated as the internet range as far as this is concerned. I'm stuck with a double NAT till I figure out how to not use my ISP provided router. (it's more complicated than a standard setup as it's fibre and does TV and phone too)

TCM · Sep 16, 2013

Wait a second. You're doing VPN to 10.1.1.15? Does that box do NAT for the VPN network? Otherwise, your PFsense needs a route to the VPN network via 10.1.1.15.

Edit: Nevermind, you got this route. Still looking.

When you try to connect to 10.1.1.10, what does

Code:

pfctl -ss | grep 10.1.1.10

look like?

Red Squirrel · Sep 16, 2013

No NAT, 10.1.1.15 is the VPN server that is behind the firewall and is on the same subnet/vlan as everything else. UDP port 25025 is forwarded and allowed in to that IP. There is also a static route so my network knows to route 10.2.1.0/24 traffic to that server. I know as a fact that works because I can ping everywhere fine. In fact it never occurred to me till now but UDP traffic IS fine because DNS (10.1.1.10 is the server) works fine too. It's only TCP that keeps getting blocked.

Sorry for the confusion, originally I was trying to set Open VPN in pfsense but gave up and want to just get the existing server to work again. It worked before I clean installed 2.0 on a new box and redid all the rules.

TCM · Sep 16, 2013

OK, apparently I'm retarded. I was partly misunderstanding the problem from just seeing the PFsense interface.

So, you have 10.1/16 on the PFsense box. 10.1.1.15 is your VPN endpoint. Why does traffic from the VPN to 10.1.1.10 even hit the PFsense box? It should go from 10.1.1.15 directly to 10.1.1.10 because they are in the same subnet.

Code:

ifconfig -a
netstat -rn

on the VPN box please.

Edit: A-HA! Your 10.1.1.10 would need a route to 10.2.1/24 via 10.1.1.15. That's it. It's really not feasible to put a VPN endpoint in the same subnet as the hosts you're trying to reach as each host would need a special route to the VPN subnet. The best thing you can do is NAT on the VPN box, put the VPN box in its own subnet or get the VPN onto the PFsense box.

Red Squirrel · Sep 16, 2013

That's odd because it worked before without a route, and ping does work. If I pint 10.1.1.10 from the vpn client it does go through. The DNS queries also work.

What if I make a vlan specifically for the vpn server and only the vpn server?

[2.0.3-RELEASE][[email protected]]/root(2): ifconfig -a
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
ether 00:1e:8c:ca:9a:27
inet6 fe80::21e:8cff:feca:9a27%bge0 prefixlen 64 scopeid 0x1
nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
ether 00:1e:8c:ca:9b:53
inet6 fe80::21e:8cff:feca:9b53%bge1 prefixlen 64 scopeid 0x2
inet 192.168.2.100 netmask 0xffffff00 broadcast 192.168.2.255
nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500
pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
pflog0: flags=100<PROMISC> metric 0 mtu 33200
enc0: flags=0<> metric 0 mtu 1536
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
bge0_vlan2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:1e:8c:ca:9a:27
inet6 fe80::21e:8cff:feca:9a27%bge0_vlan2 prefixlen 64 scopeid 0x8
inet 10.1.1.1 netmask 0xffff0000 broadcast 10.1.255.255
nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 2 parent interface: bge0
bge0_vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:1e:8c:ca:9a:27
inet6 fe80::21e:8cff:feca:9a27%bge0_vlan3 prefixlen 64 scopeid 0x9
inet 10.11.10.1 netmask 0xffffff00 broadcast 10.11.10.255
nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 3 parent interface: bge0
bge0_vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:1e:8c:ca:9a:27
inet6 fe80::21e:8cff:feca:9a27%bge0_vlan4 prefixlen 64 scopeid 0xa
inet 10.11.11.1 netmask 0xffffff00 broadcast 10.11.11.255
nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 4 parent interface: bge0
tun2: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ovpns1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:bd:04:53:3c:01
inet6 fe80::2bd:4ff:fe53:3c01%ovpns1 prefixlen 64 scopeid 0xc
nd6 options=43<PERFORMNUD,ACCEPT_RTADV>
Opened by PID 49268
tun1: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
[2.0.3-RELEASE][[email protected]]/root(3):
[2.0.3-RELEASE][[email protected]]/root(3):
[2.0.3-RELEASE][[email protected]]/root(3):
[2.0.3-RELEASE][[email protected]]/root(3): netstat -rn
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.1 UGS 0 1719767 bge1
10.1.0.0/16 link#8 U 0 553588745 bge0_v
10.1.1.1 link#8 UHS 0 0 lo0
10.2.1.0/24 10.1.1.15 UGS 0 422488 bge0_v
10.11.10.0/24 link#9 U 0 380246588 bge0_v
10.11.10.1 link#9 UHS 0 0 lo0
10.11.11.0/24 link#10 U 0 0 bge0_v
10.11.11.1 link#10 UHS 0 0 lo0
127.0.0.1 link#7 UH 0 1325 lo0
192.168.2.0/24 link#2 U 0 0 bge1
192.168.2.1 00:1e:8c:ca:9b:53 UHS 0 25685 bge1
192.168.2.100 link#2 UHS 0 0 lo0

Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UH lo0
fe80::%bge0/64 link#1 U bge0
fe80::21e:8cff:feca:9a27%bge0 link#1 UHS lo0
fe80::%bge1/64 link#2 U bge1
fe80::21e:8cff:feca:9b53%bge1 link#2 UHS lo0
fe80::%lo0/64 link#7 U lo0
fe80::1%lo0 link#7 UHS lo0
fe80::%bge0_vlan2/64 link#8 U bge0_vla
fe80::21e:8cff:feca:9a27%bge0_vlan2 link#8 UHS lo0
fe80::%bge0_vlan3/64 link#9 U bge0_vla
fe80::21e:8cff:feca:9a27%bge0_vlan3 link#9 UHS lo0
fe80::%bge0_vlan4/64 link#10 U bge0_vla
fe80::21e:8cff:feca:9a27%bge0_vlan4 link#10 UHS lo0
fe80::%ovpns1/64 link#12 U ovpns1
fe80::2bd:4ff:fe53:3c01%ovpns1 link#12 UHS lo0
ff01:1::/32 fe80::21e:8cff:feca:9a27%bge0 U bge0
ff01:2::/32 fe80::21e:8cff:feca:9b53%bge1 U bge1
ff01:7::/32 ::1 U lo0
ff01:8::/32 fe80::21e:8cff:feca:9a27%bge0_vlan2 U bge0_vla
ff01:9::/32 fe80::21e:8cff:feca:9a27%bge0_vlan3 U bge0_vla
ff01:a::/32 fe80::21e:8cff:feca:9a27%bge0_vlan4 U bge0_vla
ff01:c::/32 fe80::2bd:4ff:fe53:3c01%ovpns1 U ovpns1
ff02::%bge0/32 fe80::21e:8cff:feca:9a27%bge0 U bge0
ff02::%bge1/32 fe80::21e:8cff:feca:9b53%bge1 U bge1
ff02::%lo0/32 ::1 U lo0
ff02::%bge0_vlan2/32 fe80::21e:8cff:feca:9a27%bge0_vlan2 U bge0_vla
ff02::%bge0_vlan3/32 fe80::21e:8cff:feca:9a27%bge0_vlan3 U bge0_vla
ff02::%bge0_vlan4/32 fe80::21e:8cff:feca:9a27%bge0_vlan4 U bge0_vla
ff02::%ovpns1/32 fe80::2bd:4ff:fe53:3c01%ovpns1 U ovpns1

TCM · Sep 16, 2013

Yes, because ICMP and UDP are stateless. Currently, they go like this:

Request: 10.2.1/24 -> 10.1.1.15 -> 10.1.1.10. This works.

Reply: 10.1.1.10 -> 10.1.1.1 (because of 10.1.1.10's default route) -> 10.2.1/24 via 10.1.1.15 (because 10.1.1.1 has a route for that)

They take completely different paths, buth that's OK because they are stateless protocols. For TCP this would normally work, too, I guess, but PFsense's packet filter is blocking it because it's stateful (the packet filter) and the SYN-ACK is out of state from its point of view.

Edit: If the PFsense box can handle routing all VPN traffic, then moving the VPN server to its very own subnet would be the best option. If you rather keep the load off of PFsense, enabling NAT on the VPN server would work, too. Yes, that would be triple NAT for VPN traffic to the Internet.

Edit2: VPN on the PFsense box is of course the most elegant and preferred solution, although a VPN server in its own subnet has security benefits in case the VPN software has critical flaws.

Red Squirrel · Oct 20, 2013

Ok finally got this to work. The other solutions looked easier but lacked documentation, while OpenVPN has tons of documentation it's just the thing of finding a good tutorial. I suppose when I need something in a pinch I can just use SSH tunnels, it's rare that I'm away from home or work and need access to my network so this will do.

This is the tutorial I followed: https://www.digitalocean.com/commun...p-and-configure-an-openvpn-server-on-centos-6

I put the server on it's very own vlan and I can access all of my network now. I guess in a way this has an advantage as I can fine tune anything I don't want the vpn to be able to access.

Now to secure it further... is there anything I can do to stop brute force attacks? ex: someone making up certificates and trying to connect over and over with different certificates. I also noticed it's not prompting for a password like it used to do with my old server when it worked. Guessing I may have missed a step somewhere? How do I enable a password? If someone was to get ahold of the cert files they'd get full access to my network as it is right now, and that's kind of scary. Currently I only allow my work IP to connect but it would be nice to have it wide open so once I get it to work on my phone I can access my network monitoring and other stuff from anywhere.

Red Squirrel · Oct 20, 2013

Is it possible to create more than one user? Ex: I'd like to make another set of certs for my phone, and possibly my web server. I'd also like these to have different network permissions. Is this possible? I could make IP based rules but guessing that's not the most secure way as a potential hacker could probably do something to get a different IP.

I figured I could just run ./build-key again but it's just erroring out with this:

[root@vpnsrv easy-rsa]# ./build-key phone
Please edit the vars script to reflect your configuration,
then source it with "source ./vars".
Next, to start with a fresh PKI configuration and to delete any
previous certificates and keys, run "./clean-all".
Finally, you can run this tool (pkitool) to build certificates/keys.

If I run ./clean-all like it wants wont that wipe the existing client (laptop)?

Edit: Got it to work, turns out I need to run source ./vars for each user.

shade91 · Oct 20, 2013

If I can use OpenVPN, anyone can.

Red Squirrel · Oct 20, 2013

I don't know where people are getting that this is super easy, is there some kind of auto installer I don't know about, which auto gens everything like the certs and all that? I was doing this manually creating all the config files (some of which had to be copied from another location and the documentation is not clear on that) then all the certififactes etc. I followed the tutorial I linked to to the letter and it did work, but it's still quite an involved process and I can't imagine doing it without such tutorial.

When I was trying in pfsense it looked easier but I could just never get it to work even following tutorials so I gave up. Seems setting up a separate server is easier because there's just more tutorials on that.

If no such auto installer exists I might look at coding one. Prompts for a few basic things like the IP range, and auto generates the server config file and certs (and puts them in right location) as well as the client config files with the certs in them already and lets you download it. That's how it should be imo. I should be able to issue a command like openvpn-createuser [username] then it prompts for the optional user password, then it outputs the config file to screen so I copy and paste. Now that I figured this out I can probably go through the tutorial again and generate such a script.

/usr/home · Oct 20, 2013

Again, OVPN access server. Takes 5 mins. 2 free licenses and can get 10 more for 60 a year. Stupid easy config for desktops and phones.

Seriously, stupid easy client setup that even regular employees can use to connect.

Red Squirrel · Oct 20, 2013

That sounds like it's a commercial product that has limitations though. Anyway I got it working now so all is good. I will have to make some scripts to make the whole process easier next time though but I bookmarked that tutorial for now.

Only thing I need to figure out now is how to make access policies based on the user. I'd like to setup a persistent tunnel from my online server but I don't want the server to be able to access my network in case it ever gets compromised. (it's web facing) Is it safe to do IP based rules in my firewall or can a VPN client assign itself any IP it wants in that range? ex: is the IP forced by the VPN server or is it just telling the client to use that IP?

Shockey · Oct 21, 2013

You can setup static ip on a client by client basis (line in client config). see below for details

http://www.leonardoborda.com/blog/h...ress-to-a-openvpn-user-lan-to-lan-connection/

The only way I've ever done this is through pfsense 2.0.x with a few add on packages to export a client config in executable file. does all the configuration of network interface and also putting config file where it needs to go. This was all GUI based driven.

Red Squirrel · Oct 21, 2013

Interesting, that looks more versatile as I can push other settings too.

Question is though, can this be depended on for security? Ex: if I give my online server (the client as far as vpn goes) the IP address 10.5.5.10 is there anyway that IP could be changed if someone was to compromise that server?

Idealy if this is fool proof I can then setup firewall rules to allow/deny traffic based on the IP I assigned to each certificate and it will give me granular control.

diizzy · Oct 21, 2013

Mentioned in post #2 of this thread...
//Danne

Red Squirrel · Oct 21, 2013

I have all of that stuff working now. What I'm asking is if the client is able to override the push settings or not. That will determine whether or not I can rely on the ccd settings/static IPs for security.

Edit: I answered my own question, I was able to easily change the IP info in the settings the same way I would with a physical adapter. So now I know I can't rely on these settings for access control. For my online server I will just create a separate VPN server on another vlan. Now that I got this working I can just clone this VM and change the IP settings.

diizzy · Oct 21, 2013

...or just allow packets from the IPs you've set.
//Danne

Something easier than openvpn?

Gawd

[H]F Junkie

Fully [H]

2[H]4U

Gawd

Fully [H]

[H]F Junkie

[H]F Junkie

Fully [H]

Weaksauce

[H]F Junkie

Weaksauce

[H]F Junkie

[H]F Junkie

Weaksauce

[H]F Junkie

Gawd

[H]F Junkie

Gawd

[H]F Junkie

Gawd

[H]F Junkie

Gawd

[H]F Junkie

Gawd

[H]F Junkie

[H]F Junkie

shade91

Guest

[H]F Junkie

Supreme [H]ardness

[H]F Junkie

2[H]4U

[H]F Junkie

2[H]4U

[H]F Junkie

2[H]4U