4 ms·

wrt the IP not being enforced, do you mean different endpoints can require different IPs, or a client can connect to an endpoint with a different IP configured

wrt the IP not being enforced, do you mean different endpoints can require different IPs, or a client can connect to an endpoint with a different IP configured and it's all good? Last time I tested, if you set one IP per user in your wireguard config, that user must connect with that IP.

candiddevmike 4y ago
I believe you're referring to AllowedIPs, which is more around the IPs allowed over the tunnel. I'm talking about the non tunnel source IP of the peer. If you can copy a peers key and use the right AllowedIPs, nothing stops you from impersonating a peer. Being able to lock down peers to a source IP would fix this.
- matthewaveryusa 4y ago
  I think that goes against the tenant of wireguard working well while roaming. In general the concept of an identifying ip (outside of wireguard) will only lead to problems: devices can have multiple ips, and also share ips in the case of NAT/CGNAT. In my experience it's never been worth the trouble (again excluding wireguard)
  - candiddevmike 4y ago
    Your EC2 instance probably shouldn't be roaming to Russia though, right?
    - bongobingo1 4y ago
      You already have to open your fw for wg traffic, doesn't seem too obnoxious to just allow/drop there.
      - yardstick 4y ago
        Deny by default and Defense in depth are good security approaches in many organisations. I may have a critical server that only comes from 1-2 known, static, IPs. Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my super important server by mistake. I would prefer it simply wasn’t able to connect.
        bongobingo1 4y ago
        My point is, you deny by default and only allow your static ips at the FW. You need a firewall rule anyway to let the wg traffic through. WG was built to handle roaming, and the FW can do a great job of filtering by address already, so it makes sense to not bloat wg with extra code to me.
        yardstick 4y ago
        But the FW can’t filter by source IP and key, which is important to some people. There’s a gap in security coverage between WG and FW. This is commonly supported by IPsec implementations already. Remember your WG service could be terminating many tunnels from many different sources. Some yes roaming may be valid. Others not. There is no way in WG to selectively disable roaming for some keys but not others. This may be an intentional design decision in WG but I would argue it’s a poor one due to the above.
        bongobingo1 4y ago
        Ah yes, great point.
vetinari 4y ago
He means endpoint (hostname or IP), not AllowedIP. It is resolved/connected to only when initiating the connection, not when accepting one. I consider the behavior a feature, allows for seamless roaming. You should not trust the IPs anyway, that's what the keys are for.

candiddevmike 4y ago

I believe you're referring to AllowedIPs, which is more around the IPs allowed over the tunnel. I'm talking about the non tunnel source IP of the peer. If you can copy a peers key and use the right AllowedIPs, nothing stops you from impersonating a peer. Being able to lock down peers to a source IP would fix this.

matthewaveryusa 4y ago
I think that goes against the tenant of wireguard working well while roaming. In general the concept of an identifying ip (outside of wireguard) will only lead to problems: devices can have multiple ips, and also share ips in the case of NAT/CGNAT. In my experience it's never been worth the trouble (again excluding wireguard)
- candiddevmike 4y ago
  Your EC2 instance probably shouldn't be roaming to Russia though, right?
  - bongobingo1 4y ago
    You already have to open your fw for wg traffic, doesn't seem too obnoxious to just allow/drop there.
    - yardstick 4y ago
      Deny by default and Defense in depth are good security approaches in many organisations. I may have a critical server that only comes from 1-2 known, static, IPs. Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my super important server by mistake. I would prefer it simply wasn’t able to connect.
      - bongobingo1 4y ago
        My point is, you deny by default and only allow your static ips at the FW. You need a firewall rule anyway to let the wg traffic through. WG was built to handle roaming, and the FW can do a great job of filtering by address already, so it makes sense to not bloat wg with extra code to me.
        yardstick 4y ago
        But the FW can’t filter by source IP and key, which is important to some people. There’s a gap in security coverage between WG and FW. This is commonly supported by IPsec implementations already. Remember your WG service could be terminating many tunnels from many different sources. Some yes roaming may be valid. Others not. There is no way in WG to selectively disable roaming for some keys but not others. This may be an intentional design decision in WG but I would argue it’s a poor one due to the above.
        bongobingo1 4y ago
        Ah yes, great point.

vetinari 4y ago

He means endpoint (hostname or IP), not AllowedIP. It is resolved/connected to only when initiating the connection, not when accepting one. I consider the behavior a feature, allows for seamless roaming. You should not trust the IPs anyway, that's what the keys are for.