IPVLAN overrides the bridge network and can no longer access the ports

General
1

Hi,

I have a container setup with compose and a bridge backend network and a IPVLAN network to access physical devices on the network.

The problem I am having is when I enable the IPVLAN the bridge stops working. I would like both of them to work independently. With just the bridge enabled I can access my web app with my pc hostname and the port hostname:1881 and it works fine. As soon as I enable the IPVlan I no longer have access via the hostname. Only way to gain access to the web app is now to use the vlan Ip address and port vlanIP:1881

The vlan works and allows me to access devices on my local network ( in my case PLCs via OPC-UA ) I would still like to access the web interface via the hostname since these IPs will always get changed etc

EDIT: I forgot to mention I don’t want to use host networking since I need to map the ports. I will have multiple of these running on the same network and need different ports per device to access the web interfaces.

version: '3.3'
services:
   fuxa:
       image: frangoteam/fuxa:latest
       ports:
           - 1881:1881
       volumes:
           - ./fuxa_appdata:/usr/src/app/FUXA/server/_appdata
           - ./fuxa_db:/usr/src/app/FUXA/server/_db
           - ./fuxa_logs:/usr/src/app/FUXA/server/_logs
           - ./fuxa_images:/usr/src/app/FUXA/server/_images
       restart: always
       networks:
           backend:
               ipv4_address: 172.20.0.5
           lan:
               ipv4_address: 192.168.10.220
networks:
 backend:
   name: Backend
   driver: bridge
   ipam:
     driver: default
     config:
       - subnet: 172.20.0.0/24
         gateway: 172.20.0.1
 lan:
   name: Lan
   driver: ipvlan
   driver_opts:
     parent: eth0
   ipam:
     driver: default
     config:
        - subnet: 192.168.10.0/24
          gateway: 192.168.10.1
          ip_range: 192.168.10.0/24
2

Both networks should be able to co-exist and work at the same time. At least this is what it does when macvlan is used, so assume it will be the same for ipvlan. The only limitation with ipvlan/macvlan is that child interfaces (what the container uses) are not allowed to directly communicate with the parent interface (driver_opts.parent) - this is not docker’s doing, it is a security mechanism of the host’s kernel.

I have no idea what PCLs via OPC-UA means, but ipvlan and macvlan usually make sense when you need your container to react to network broadcast messages, or to simply want to have a container ip from within your lan subnet range. It is generally a good idea to declare an ip_range with a cidr within your subnet that is excluded from your lan’s dhcp.

A container on a bridge network can access everything the host can access as well. It is not required to add an ipvlan/macvlan network to access other devices from your local lan.