PFSense 2.0 - Not able to bridge tap VPN.

xhark

this issue will be fixed in the next release?

firbc

Try going to 'Interfaces' > 'assign' and create an interface for 'ovpns1'

Then enable it under the interface drop down list, then go back to assign interfaces and you should be able to bridge the LAN and OVPN interfaces

See attached screenshots, let me know if it works.

Also for my bridged client setup I had to modify the /var/etc/openvpn/server1.conf

dev ovpns2
dev-type tap
dev-node /dev/tap2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local x.x.x.x
tls-server
mode server <–---removed 'server x.x.x.x'
client-config-dir /var/etc/openvpn-csc
lport 1195
management /var/etc/openvpn/server2.sock unix
ca /var/etc/openvpn/server2.ca
cert /var/etc/openvpn/server2.cert
key /var/etc/openvpn/server2.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server2.tls-auth 0

how did you set mode "server <–---removed 'server x.x.x.x'" to stay in config after reboot?

Jarpse

This might be a slight kick, but did you try a (bogus) /30 subnet on the TAP? Don't forget to bridge the interface and allow traffic on the created OPT interface (Which you need to create a bridge, anyway).

jimp

The code for tap on 2.0 is a bit broken. I fixed it up and it's now working on 2.1.

https://github.com/bsdperimeter/pfsense/commit/1ab6bdb5ffcf052241f58af87efef9fe077b38c7
https://github.com/bsdperimeter/pfsense/commit/74a556a3caa67adb0adac055ffb9321e264e1b71

sbeaudoin

Sorry to all, but I did not have time to try your suggestions. I think i will wait until 2.1 is released if it is not too far. Any date yet?

jimp

No idea, probably on the order of 4-6+ months.

It wouldn't be hard to adapt those changes to 2.0.1 but I'm not sure if the impact of the change would be considered too large to pull back from 2.1, considering we're trying to get 2.0.1 out in just a few days time.

Jarpse

Please, do try to get it in 2.0.1. The changes in the two files don't seem like they break machines or vpns when you update 'em to 2.0.1, or do they? ;-) As the code for tun interfaces stays the same.

Quite a few people have problems with the tap interface. I would be really grateful if it'd be fixed in 2.0.1.

tugi

Hi!

Have you seen it? - http://doc.pfsense.org/index.php/OpenVPN_Bridging

I have successfully setup bridge between LAN and tap on the 2.0 version.

sbeaudoin

No, but you have seen the following, I suppose :

_Caveat - There are some problems with the setup described here, this is currently being refactored.

THIS CANNOT BE USED ON 2.0._

tugi

Yes, But it works fine on 2.0 :)

ghowey

Can we get our hands on version 2.1?

jimp

You can install the tap fix patch package I put up for 2.0 (though it needs updating… not so easy as the fixes don't merge cleanly from 2.1), and if you want 2.1 you can use gitsync to get the code, check the doc wiki for instructions.

ghowey

Ah, I did not realize that you had added a Tap Fix Package for OpenVPN. It is now installed! Thank You, and Thanks for pfSense.
It does everything I need for my SOHO Gateway and more, with minimal resources!

dig1234

I've got that fix package installed and indeed it makes smart changes to the GUI, but still no dice for me. I cannot for the life of me get pings to work from the clients. I know the tunnel is working because I can actually see some layer 2 traffic going across the tunnel (ARP broadcasts, multicasts) with tcpdump. But pinging etc will not work even to the pfsense box itself. It feels like a firewall issue but I've got allow * rules on all interfaces including the OPT1 bridge.
Been struggling with this for a week any suggestions?
Here is my tap config:

tap.jpg_thumb

jimp

Show the output of "ifconfig -a"

Also if you switched between tun/tap on an existing connection, you must reboot. An unfortunate fact of dealing with tap interfaces.

New connections should be fine for that, you just need to make sure they're assigned and bridged to LAN on both sides.

dig1234

Here is the output (note:the lan iface is dot1q trunked into the switch.)

em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 150 0
options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:0c:29:af:78:7e
inet6 fe80::20c:29ff:feaf:787e%em0 prefixlen 64 scopeid 0x1
inet 10.0.1.253 netmask 0xffffff00 broadcast 10.0.1.255
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
plip0: flags=8810 <pointopoint,simplex,multicast>metric 0 mtu 1500
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 0x3
nd6 options=3 <performnud,accept_rtadv>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
em0_vlan2: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 m tu 1500
options=3 <rxcsum,txcsum>ether 00:0c:29:af:78:7e
inet6 fe80::20c:29ff:feaf:787e%em0_vlan2 prefixlen 64 scopeid 0x7
inet 10.0.6.253 netmask 0xffffff00 broadcast 10.0.6.255
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 2 parent interface: em0
bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
ether f2:39:a5:31:42:98
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: ovpns1 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 9 priority 128 path cost 2000000
member: em0_vlan2 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 7 priority 128 path cost 20000
ovpns1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=80000 <linkstate>ether 00:bd:39:07:00:01
inet6 fe80::2bd:39ff:fe07:1%ovpns1 prefixlen 64 scopeid 0x9
nd6 options=3 <performnud,accept_rtadv>Opened by PID 48350
ovpns3: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
options=80000 <linkstate>inet6 fe80::20c:29ff:feaf:787e%ovpns3 prefixlen 64 scopeid 0xa
inet 10.0.7.1 –> 10.0.7.2 netmask 0xffffffff
nd6 options=3 <performnud,accept_rtadv>Opened by PID 13380
tun1: flags=8010 <pointopoint,multicast>metric 0 mtu 1500
options=80000 <linkstate>pptpd0: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd1: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd2: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd3: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd4: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd5: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd6: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd7: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd8: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd9: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd10: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd11: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd12: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd13: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd14: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500
pptpd15: flags=8890 <pointopoint,noarp,simplex,multicast>metric 0 mtu 1500</pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></pointopoint,noarp,simplex,multicast></linkstate></pointopoint,multicast></performnud,accept_rtadv></linkstate></up,pointopoint,running,multicast></performnud,accept_rtadv></linkstate></up,broadcast,running,promisc,simplex,multicast></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum></up,broadcast,running,promisc,simplex,multicast></promisc></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></pointopoint,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,promisc,simplex,multicast>

jimp

That appears to be OK at a glance. Looks about like my VM test setup that works (though it doesn't use vlans)

dig1234

that's exactly what it is, if this works then I get to buy me real hardware to use for pfSense. The vlan part of it works fine, I can ping on lan etc. But what to do about TAP?! driving me crazy.
How can I test firewall rules?

jimp

Set the rules you have to log - if the packets hit the rule and log as being passed, then firewall rules are not your problem.

Doing captures on the tap interface on both ends while you try can help.

Is this a site-to-site or are you bridging in remote access clients?

dig1234

Ok- I solved it. There is a problem with bridging the vlan interface. Either a bug or a incompatibility. I noticed a message on the console something to the effect of problem adding the vlan-iface to bridge0. (I had only been using ssh so hadn't seen the message) So I switched off a vlan interface to a real one and all was copacetic. Too many variables makes for a tough diagnosis.. Thanks for your help!