Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    how does same IP on two interfaces work? / TINC

    Scheduled Pinned Locked Moved General pfSense Questions
    4 Posts 2 Posters 563 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      coreybrett
      last edited by coreybrett

      When using recommended settings for TINC the LAN and TUN interfaces are configuered with the same IP address but different masks.

      How does that work (which it does) and not cause a conflict for the LAN address?

      alt text

      em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
      	options=4209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
      	ether 00:0f:fe:73:5f:26
      	hwaddr 00:0f:fe:73:5f:26
      	inet6 fe80::20f:feff:fe73:5f26%em0 prefixlen 64 scopeid 0x1
      	inet 192.168.117.1 netmask 0xffffff00 broadcast 192.168.117.255
      	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
      	media: Ethernet autoselect (100baseTX <full-duplex>)
      	status: active
      tun0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu 1500
      	options=80000<LINKSTATE>
      	inet 192.168.117.1 netmask 0xffff0000 broadcast 192.168.255.255
      	inet6 fe80::20f:feff:fe73:5f26%tun0 prefixlen 64 scopeid 0x9
      	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
      	groups: tun pkg_tinc
      	Opened by PID 55135
      
      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Interesting, I'd not noticed that before.

        It works in FreeBSD because it can accept a more specific route. So in this case LAN traffic is still sent to em0 because the /24 is more specific than the /16 used for the tun interface.

        Steve

        1 Reply Last reply Reply Quote 0
        • C
          coreybrett
          last edited by

          thanks for the input, I see that the routing table is the key to this method

          it just seems so "wrong" to have the same address on two different interfaces

          it also doesn't work out if you have other subnets not covered by the same mask

          after exchanging emails on the tinc mailing list, I've decided to put a different IP on the tunnel interface and use the "subnet up" script to handle adding routes

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Yes I agree, I seems unnatural to do that. 😉

            However I guess that by doing that you can add new nodes to the mesh and as long as they are in that subnet the system routing table does not have to change to reach them. Only the internal routing in the daemon.

            Steve

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.