Messages

1

20.1 Legacy Series / Re: CARP issue with one single VLAN - backup on both units

« on: May 17, 2020, 11:59:16 am »

I was playing w/ CARP yesterday and saw just that on a VLAN interface, except in my case both router instances thought they were master.

That was using an iffy virtualbox network, I thought VLAN was not supported somehow, but apparently the problem might not be with VB.

The interface itself worked ok and the sync link as well, no issue with other  “native” interfaces.

2

Intrusion Detection and Prevention / IPS questions, topology, platform requirements

« on: April 25, 2020, 12:44:41 am »

Hi all.
I've been asked to look into an IPS for a small Lan.

The need is for an active type of thing that would block traffic. I imagine the platform needs to to be installed behind the router, running the IPS process over an anonymous bridge, correct?

Do you think a gen-9 Poweredge running OVPN, with 2xDual Core 51xx Xenon, and the dual broadcom NetxtremeII Gigabit ethernet interface can be a good (transparent) platform?

Thanks in advance for your advice.

3

18.1 Legacy Series / Re: OpenVPN Tap tunnel, how to ?

« on: May 06, 2018, 12:37:58 pm »

I can't say much, I don't understand what's going on.
I have raised a topic on this, Franco had a look and it has gone quiet. I hope the OPNsense guys have an interest in testing such a config and will sometime confirm/infirm the bug.

What does not work:
 - assign a vlan, say igb0.66
 - assign any other interface, say tap0
 - assign a bridge with igb0.66 and tap0
What happens: machines on igb.66 get an IP address and then cannot communicate with tap0 and beyond. They can communicate with each other IIRC.

What does work:
 - Replace igb0.66 with a native interface, say igb2
What happens: machines on igb2 get an IP address and can communicate with tap0 and beyond.

If you have a leftover physical interface on the router, try to dedicate it to the telephone network.
Otherwise, let me know how to make a VLAN work in this configuration!

Cheers

4

Tutorials and FAQs / And now site-to-site static key bridged mode - OPNsense 17.7, 18.1

« on: April 25, 2018, 05:09:43 pm »

A quick follow-up, here is the recipe for a site-to-site bridged config.
The idea is to let the router on site A manage site B completely, esp. via its DHCP server. This is why none of the special OpenVPN options related to client management are used (IP pool, Bridge settings...)

The motions you'll have to go through will be more accurately described in the FP, but basically this is the workflow for both sites:

• Create a bridge, assign an interface,— NB: not a VLAN it does not work AFAIK
• Create your OVPN client or server config, select tap and your options,
• Activate the created ovpn<s|c><number> interface and assign it to the bridge, (ovpncX = client tap #X, ovpnsY = server tap #Y)
• (Re)Start the OVPN instance,
• Check your filtering rules.

Make sure your IP setup does not conflict across sites, you're on a single network.
In this example you just need to configure the DHCP server on site A, but in general using a 172.16/12 or 10/8 network for your sites can make management easier.

Now the OVPN settings for a site-to-site static key setup.
The following setup should work as-is with net.link.bridge.pfil_member=0 and net.link.bridge.pfil_bridge=1 set in System>Settings>Tunables
If you don't set these, you'll need to define filtering rules per bridge member interface. This was not tested, you're on your own.

• Server side
  On site A router, go to VPN>OpenVPN>Servers, click on "Add server".
  Here are the main options you want to set:
• General info:
  Server Mode: Peer to Peer (Shared Key)
  Device mode: tap
  Interface: <your WAN interface>
  
• Crypto settings:
  Shared Key, select "Automatically generate a shared key."
  Encryption, Auth, Hw crypto: YMMV, I suggest you start with the defaults.
  
• Tunnel Settings:
  Everything empty, except:
  Compression: Select "Enabled w/ Adaptive Compression" (whatever you choose, make sure both sides match)
  Type-of-Service: selected. Both options mildly useful but they don't hurt AFAIK.
  Yes, bridge interface is set to "none". The DHCP server on site A manages the network.
  
• Client settings:
  All empty. Uncheck Address Pool.
  
• Advanced:
  dev tap
  persist-tun
  ifconfig-nowarn
  ping-timer-rem
  
Now Save, assign the ovpnsX interface to the bridge, restart the OVPN server. It should go green.
Check your incoming filtering rule on the WAN interface to allow the client to connect. BTW, prefer udp rather than tcp for the tunnel, tcp-over-tcp can cause more issues than it solves.
Go back to the server configuration and copy the generated key. You'll need to paste it in the client config.

• Client side
  On site B router, make sure the DHCP server is deactivated on the bridged interface.
  Then go to VPN>OpenVPN>Clients, click on "Add client".
  Here are the main options you want to set:
• General info:
  Server Mode: Peer to Peer (Shared Key)
  Device mode: tap
  Interface: <your WAN interface>
  Remote Server: <public IP or name of site A>
  Retry DNS resolution: check "Infinitely resolve remote server"
  
• User Authentication Settings: leave empty
• Crypto settings:
  Uncheck "Automatically generate a shared key.", then paste the key that was generated on the server side. (or your secret won't match)
  Encryption, Auth, Hw crypto: if you changed anything to the default, check you match settings on the other side.
  
• Tunnel Settings:
  Everything empty, except:
  Compression: Select "Enabled w/ Adaptive Compression" (whatever you choose, make sure both sides match)
  Type-of-Service: selected. Both options mildly useful but they don't hurt AFAIK.
  
• Advanced:
  dev tap
  persist-tun
  ifconfig-nowarn
  
Now Save, assign the ovpncX interface to the bridge, restart the OVPN client. It should go green.
Check your filtering rule on the bridged interface. You can open IPv4 any to any and set the gateway for that rule to the automatically generated <ovpncX_name>_VPNV4 gateway.
If you create a schedule (Firewall>Settings>Schedules) you can activate/deactivate the rule according to time-of-day.

You now have a single LAN spanning over 2 sites, congratulations.

5

17.7 Legacy Series / Re: Bridging vlans - 17.7

« on: April 25, 2018, 03:29:06 pm »

Yes I think it's broken in BSD. I've had the same issue in 17.17.12 and 18.1.6?, a tagged interface doesn't really work in a bridge. Non-IP traffic works (eg a DHCP lease) but L3 is dead.
Doesn't look like a new problem, and doesn't look like it's OPNsense-specific.

I'd like to be wrong, though.

6

18.1 Legacy Series / Re: OpenVPN Tap tunnel, how to ?

« on: April 25, 2018, 03:06:28 pm »

What part of the linked tutorial is unclear?

About the post in the how-to section about tap, at the beginning it is written that "this works for peer-to-peer mode as well" So in that case, I have to do the same bridge on the distant server no ? And the mode server is useless ?

I suggest you stick to the how-to and then derive your own config. "server mode" is fine even for site-to-site.
EDIT: I've  added a recipe for site-to-site in the howto thread.

The other day I used a pair of 17.7 (also works on 18.1) to setup a bridged site-to-site link. This one uses a shared static key, no problem with expiry dates and time-of-day. There is a server bridged as in the howto, there is a client bridged in the same way on the other side. (in ovpn parlance this is p2p mode, "server" is the side that listens passively, "client" is the side that actively calls)
In the "Advanced" field, choosing the right options is a little bit tricky, because your GUI settings generate options/values, and what you want to add in Advanced is options that complement or override, but not clash with the generated ones. OTOH you want to have "dev tap" and "preserve-tun" in the Advanced field on both sides.

BTW If not said before: I don't see the need for a DHCP relay since with bridging you're on a single subnet... If the link is too poor for DHCP leases req/offers to reach the intended targets, filter out the eventual incoming responses from the remote server (you can't filter out outgoing queries I think) and start another authoritative server on the local router. Make sure your IP lease pool does not clash with the one on the other side. It's all the same network.

And no, bridge member interfaces do not have an IP config. Only the bridge has an IP config (or none if you want a transparent bridge.)

7

Tutorials and FAQs / Re: How-to: OpenVPN in bridged mode - OPNsense 17.1, 17.7

« on: April 25, 2018, 02:40:31 pm »

FYI, still ok on 18.1.

8

18.1 Legacy Series / Re: DHCP relay over VPN ?

« on: April 19, 2018, 03:37:07 pm »

DHCP uses 67/udp and 68/udp.
If a server receives a request (on 67/udp) you should see it in its logs.
If the local firewall blocks the server response (on 68/udp) you should see it in OPNsense logs.
Perhaps that traffic is classified as bogon, enable logging on anti-bogons rules.

9

18.1 Legacy Series / Re: Q 17.7.12 vs 18.1 - VLAN in bridge working?

« on: April 18, 2018, 01:18:54 am »

I really think it's hosed.

Bridge 1 on IGB1, no VLAN: DHCP and ping works for clients (192.168.1.0/24)
+ add VLAN 20 on IGB1, give it an IP: DHCP and ping works for clients (192.168.5.0/24) -> switch config is ok.
- unconfigure IGB1.20
+ make IGB1.20 a member of Bridge 2, give the former IP config to Bridge 2: DHCP works for clients (192.168.5.0/24), clients can't ping or communicate with the router. Router can't ping client.

I ran a tcpdump and IGB1.20 does receive traffic. There is never a reply so I suppose the traffic vanishes past IGB1.20
Unlike linux it's not possible it seems to attach a VLAN ID to the bridge itself, so I couldn't try that.

10

18.1 Legacy Series / Re: Q 17.7.12 vs 18.1 - VLAN in bridge working?

« on: April 17, 2018, 11:02:15 pm »

Hiya Franco,
Agreed those pesky PVIDs and tags can cause problems... I think I will check again but I'm pretty sure it's not a switch setup issue.
The thread I wanted to refer to is not so old in fact: https://forum.opnsense.org/index.php?topic=3753.msg13804#msg13804
Unlike the OP I did not take the time to tcpdump the traffic.
There isn't heaps of bridge/vlan bugs opened in FreeBSD, but I'm not sure my case relates to one.

Anyways, if I check again and find my switch setup was faulty, I will post an update here.
Thanks!

11

18.1 Legacy Series / FYI: weird non-deletable OVPN_VPNV4 Gateway created by OVPN client

« on: April 17, 2018, 01:01:06 pm »

As an aside to my previous question, I have noticed on both 17.7.12 and 18.1.6 that a strange gateway is created by OPNsense when using a client tap OpenVPN deamon bridged to an anonymous (no IP) bridge.

The thing is called "OVPN_VPNV4 Gateway" (or VPNV4 Gateway?) and I have no idea which purpose it serves.
I tried deleting it and it comes back stubbornly in the list of gateways. Since it is created, renaming it is not possible either.
However it is possible to disable it, which hides it from the Dashboard. That's what I elected to do.

12

18.1 Legacy Series / Q 17.7.12 vs 18.1 - VLAN in bridge working?

« on: April 17, 2018, 12:10:02 pm »

Hi there.
I was asked to setup a site to site bridge between 2 sites with identical networks. The router at each site is an APU2 running OPNsense 17.7.x.

I elected to use OpenVPN over an anonymous bridge in order to avoid the routing issue.
On 17.7.12, my remote clients were able to get a DHCP lease from the other side, but then they couldn't ping anybody except their neighbours on the switch.
I traced that down to my use of a VLAN over ibg1 as a bridge member. As soon as I used a VLAN-free opt1 (igb2) interface, my clients were ok.

I've found a rather old thread (15.7 ?) relating to issues using VLANs as bridge members.
I didn't test with 18.1, I would like to know if someone can confirm the issue still exists, and if there is a workaround?

Thanks!

13

18.1 Legacy Series / Re: Basic mDNS question

« on: February 19, 2018, 11:13:32 am »

The m in mDNS means multicast. mDNS is a name resolution system in which there is no central server. All machines receive queries and reply, over 224.0.0.251 port 5353/udp.
224.0.0/24 is a local-only network. It is not routed, as per IETF RFC somesuch.
So either you bridge and there is no network boundaries to cross, or you use a proxy standing on each side of the network border to help multicast packets across. IGMP is the IPv4 protocol used for multicast routing on local networks.

About the .local domain name. mDNS is local in nature, DNS is routed and often public. mDNS records are short-lived, DNS records are usually cached for a while.
They don't mix well, so in order to avoid random mDNS requests leak into the DNS infrastructure, clients are generally set to try mDNS resolution *only* for the mDNS domain name, and try DNS for other domains names.
This is what the help text in OPNsense says: don't use .local as DNS name or mDNS clients won't resolve non-mDNS hosts names because i. these don't respond directly over mDNS and ii. the DNS server will never be queried for them.

Since mDNS is configured locally in so many (ephemeral) clients, changing the mDNS domain to .foobar is impractical. So the simple rule is "don't use .local as your local DNS domain".

14

17.7 Legacy Series / Tragic mistake: remotely disabling OVPN server is too easy

« on: December 02, 2017, 06:15:40 pm »

This just happened to me...

I wanted to check the settings for an OpenVPN server, while using the tunnel at the same time.
I don't know why but I am attracted to the "play" icon in the list of tunnels.
A swift click to the left of that line instead of the right and I promptly shot myself in the foot by disabling the tunnel

Would you consider adding a confirmation step when disabling a server config?
Thanks!

(I will survive, the server is not too far away.)

15

17.7 Legacy Series / [17.7.8-i386] Aliases - Nested port aliases no longer working?

« on: November 28, 2017, 09:59:30 pm »

In 17.7 I was using aliases like this:
 - "TCP_web" -> 80,443
 - "TCP_hostX_allowed" -> 1194,TCP_web

It looks like this is no longer working in 17.7.8-i386?