Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Apr 2019 19:35:02 +0200
From:      Lars Lindstrom <lars.lindstrom@gmx.at>
To:        freebsd-net@freebsd.org
Subject:   Accept network packet if destination is on the origin segment
Message-ID:  <e06e520a-17e0-412b-e2b7-cf15ff324118@gmx.at>

next in thread | raw e-mail | index | archive | help
I am operating a server hosting a set of services, each run in a
separate Docker container. In addition, there is a KVM running pfSense
based on FreeBSD 11.2-RELEASE-p3 acting as firewall. The firewall has a
physical interface that is connected to the external network and a
virtual network card that is connected to the internal container
network, using MACVLAN Docker-side, so each container has its own IP
address, but all of them are on the same subnet.

For security reasons, the containers need to be isolated and shall not
be able to communicate with each other principally (just with the
external network). For this, MACVLAN is configured in VEPA mode, which
allows traffic from and to the parent device, but not to other addresses
on the same parent device.

Now, I would like to allow specific traffic between specific containers,
using pfSense as router, considering the configured firewall rules.
However, I cannot seem to get this scenario working.

As it looks like, FreeBSD drops each packet on the virtual network card
targeting a host on the same subnet (if the destination is on the
same segment as the origin segment). I assume this is the standard
behaviour if hairpinning (or reflective relay as some call it) is not
activated, because in theory the receiver has already had a chance
to see the frame - but has not in this case.

Is there any option to activate hairpinning for a bridge (as for
instance the 'hairpin' switch for a Linux bridge) or, better (as it
requires no bridge), disable this behaviour for a specific interface?

Might there be another reason for this behaviour?




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e06e520a-17e0-412b-e2b7-cf15ff324118>