Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

StepCommand

ip tuntap add dev my_tap0 mod tap


ip link set my_tap0 up

ip link add name my_bridge type bridge

ip link set my_bridge up

ip link set <physical-int> master my_bridge

ip addr delete <ip-address>/<netmask> dev <physical-int>

ip addr add <ip-address>/<netmask> dev my_bridge

ip link set my_tap0 master my_bridge

Previous Workaround for Lack of TAP Support

The below may be obsolete - not yet clear if PAR3 will support TAP interfaces.

This chapter shows a workaround for PA3 models by which Charon-PAR traffic can use a virtual bridge on Linux. This is not the recommended configuration, but may be useful in several situations, for example:

  • The host system only has one physical Ethernet port.
  • There is a requirement to filter traffic to/from the guest system using a firewall on the host.

Please note: Do not use this workaround in an VMware environment. Instead add additional vNICs to the virtual machine to provide dedicated interfaces to the guest system as needed.

Workaround Description

The workaround is implemented using a virtual bridge and a veth interface pair. The following image shows an overview of the components:

Image Removed

...

classpagebreak

Configuration Steps

The following steps show how to set up a virtual bridge and how to attach a veth interface to it. Such commands would have to be made persistent by creating an appropriate startup script.

The commands to create the above construction are as follows (execute them as the root user):

...

After this configuration, both the host and the guest system can use the physical interface for communication. If required, firewall rules for bridge traffic can be added.

...

Linux Firewalls and Virtual Bridges

If firewall rules are to be used for bridged traffic, the kernel can be instructed to apply iptables (also arptables and ip6tables) rules to bridged traffic. In older versions, this option was included in the bridge functionality itself. Starting with kernel 3.18, the filtering functionality in the form of the br_netfilter module was moved into a separate module that can be loaded by the user if required. If the module is not loaded, no firewall rules are applied to bridge traffic and no further actions are required to pass the bridged traffic through the Linux host system.

To use the firewall for bridged traffic on newer Linux kernels, the module must be loaded using the command

# modprobe br_netfilter

or by defining an iptables rule that uses the physdev module.

After the module has been loaded, the system configuration parameters

  • net.bridge.bridge-nf-call-iptables
  • bridge-nf-call-arptables
  • bridge-nf-call-ip6tables

become available.

They are set to 1 by default (equivalent to echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables). This value enables iptables rules for bridged traffic.

Setting the parameters to 0 will disable the firewall rules. They can be set permanently via /etc/sysctl.conf.

To allow bridged traffic through the enabled firewall, use commands like the following:

# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 \

-m physdev --physdev-is-bridged -j ACCEPT

# firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 \

-m physdev --physdev-is-bridged -j ACCEPT

# firewall-cmd --reload

Please refer to the documentation of your host system for more detailed information.

Please note: at the time of writing, this feature is not yet available for nftables.


Div
classpagebreak



Include Page
KBCOMMON:DOC-GoToToc
KBCOMMON:DOC-GoToToc