[Openvpn-users] Providing routing for a whole IPv6 subnet

2021-07-17 Thread dashdruid via Openvpn-users
Hello List,

I have the following setup.

Internet -> VPNServer -> VPNClient -> LAN Subnet
   ETH0   TUN0  TUN0 BR0

I have given a /48 netblock from the ISP for my VPN server.

VPNSRV_EXT 2a02:111::333:444:55:666:1/48
VPNSRV_INT 2a02:111::333::1/64

VPNCLN_EXT 2a02:111::333::1000/64
VPNCLN_INT 2a02:111::1::1/64

Up until this point the VPNCLIENT it works by running NDPPD on the servers 
public interface advertising the 2a02:111::333::/64 network. The VPNclient 
is fully reachable on it's IPV6 address from the outside and it can also 
connect anywhere.

Now the next step would be to make it's entire subnet reachable the same way so 
I have configured another /64 network on the internal interface which is 
basically LAN bridge (br0) and I have enabled ipv6 forwarding on the VPNCLIENT.

If I try to ping the internal bridge ip of this client from the vpn server it 
is not reachable, I have even configured ndppd on the tun0 interface to 
advertise that network, however I'm not sure that this daemon can operate on 
tun interface it might needs tap since it's some layer 2 discovery thingy.

Even if I try to add a static route for the network on the VPN server it does 
not go into the tunnel interface:

ip -6 r a 2a02:111::1::/64 via 2a02:111::333::1000

I assume I might messed something up with the subnetting. Any ideas?

Thanks




___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] Providing routing for a whole IPv6 subnet

2021-07-17 Thread Antonio Quartulli
Hi,

Glad to see more people playing with IPv6 subnets :-)

On 17/07/2021 11:52, dashdruid via Openvpn-users wrote:
> Hello List,
> 
> I have the following setup.
> 
> Internet -> VPNServer -> VPNClient -> LAN Subnet
>ETH0   TUN0  TUN0 BR0
> 
> I have given a /48 netblock from the ISP for my VPN server.
> 
> VPNSRV_EXT 2a02:111::333:444:55:666:1/48
> VPNSRV_INT 2a02:111::333::1/64
> 
> VPNCLN_EXT 2a02:111::333::1000/64
> VPNCLN_INT 2a02:111::1::1/64
> 
> Up until this point the VPNCLIENT it works by running NDPPD on the servers 
> public interface advertising the 2a02:111::333::/64 network. The 
> VPNclient is fully reachable on it's IPV6 address from the outside and it can 
> also connect anywhere.
> 
> Now the next step would be to make it's entire subnet reachable the same way 
> so I have configured another /64 network on the internal interface which is 
> basically LAN bridge (br0) and I have enabled ipv6 forwarding on the 
> VPNCLIENT.
> 
> If I try to ping the internal bridge ip of this client from the vpn server it 
> is not reachable, I have even configured ndppd on the tun0 interface to 
> advertise that network, however I'm not sure that this daemon can operate on 
> tun interface it might needs tap since it's some layer 2 discovery thingy.

If you want to use ndppd, you may indeed require a L2 tunnel, but in
this scenario ndppd is not really needed (I'd actually avoid using it a
all, but I leave that to you).

This can all just work with proper routing.

One thing I can immediately see that you are missing is telling the
OpenVPN server "where" 2a02:111::1::1/64 is located.

So the VPN server needs 2 things:
1) a route that says: "to reach 2a02:111::1::1/64 please forward
related packets to tun0"
2) an "iroute" that says: "to reach 2a02:111::1::1/64 please forward
related packets to the VPN client named "VPNClient".

Point 1) is about the server standard routing table while 2) is about
the OpenVPN internal routing table.

Both points can be achieved by means of OpenVPN configuration.

1) add the following directive to your server config:

route-ipv6 2a02:111::1::/64

2) add the following directive to the CCD file (check
--client-config-dir in the manpage) specific for the client serving this
subnet:

iroute-ipv6 2a02:111::1::/64


At this point the OpenVPN server has an idea where to send packets when
they have a dst IP belonging to that subnet.

> 
> Even if I try to add a static route for the network on the VPN server it does 
> not go into the tunnel interface:
> 
> ip -6 r a 2a02:111::1::/64 via 2a02:111::333::1000

It seems you were trying to achieve almost what I explained above :-)


For what concerns the "way out" (i.e. sending packets from the LAN
behind BR0 towards the Internet), you just have to make sure that
VPNClient is doing proper routing, but I believe it is, otherwise other
things would break.


Please let us know if this helps!


Cheers,


-- 
Antonio Quartulli


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users


Re: [Openvpn-users] Providing routing for a whole IPv6 subnet

2021-07-17 Thread dashdruid via Openvpn-users
Hello,

Thanks a lot, it worked.
The only trick still needed was to add another rule as well in the ndppd.conf 
on the server machine to advertise the inside subnet on it's public eth0 
interface.



‐‐‐ Original Message ‐‐‐

On Saturday, July 17th, 2021 at 1:34 PM, Antonio Quartulli  
wrote:

> Hi,
>
> Glad to see more people playing with IPv6 subnets :-)
>
> On 17/07/2021 11:52, dashdruid via Openvpn-users wrote:
>
> > Hello List,
> >
> > I have the following setup.
> >
> > Internet -> VPNServer -> VPNClient -> LAN Subnet
> >
> > ETH0 TUN0 TUN0 BR0
> >
> > I have given a /48 netblock from the ISP for my VPN server.
> >
> > VPNSRV_EXT 2a02:111::333:444:55:666:1/48
> >
> > VPNSRV_INT 2a02:111::333::1/64
> >
> > VPNCLN_EXT 2a02:111::333::1000/64
> >
> > VPNCLN_INT 2a02:111::1::1/64
> >
> > Up until this point the VPNCLIENT it works by running NDPPD on the servers 
> > public interface advertising the 2a02:111::333::/64 network. The 
> > VPNclient is fully reachable on it's IPV6 address from the outside and it 
> > can also connect anywhere.
> >
> > Now the next step would be to make it's entire subnet reachable the same 
> > way so I have configured another /64 network on the internal interface 
> > which is basically LAN bridge (br0) and I have enabled ipv6 forwarding on 
> > the VPNCLIENT.
> >
> > If I try to ping the internal bridge ip of this client from the vpn server 
> > it is not reachable, I have even configured ndppd on the tun0 interface to 
> > advertise that network, however I'm not sure that this daemon can operate 
> > on tun interface it might needs tap since it's some layer 2 discovery 
> > thingy.
>
> If you want to use ndppd, you may indeed require a L2 tunnel, but in
>
> this scenario ndppd is not really needed (I'd actually avoid using it a
>
> all, but I leave that to you).
>
> This can all just work with proper routing.
>
> One thing I can immediately see that you are missing is telling the
>
> OpenVPN server "where" 2a02:111::1::1/64 is located.
>
> So the VPN server needs 2 things:
>
> 1.  a route that says: "to reach 2a02:111::1::1/64 please forward
>
> related packets to tun0"
> 2.  an "iroute" that says: "to reach 2a02:111::1::1/64 please forward
>
> related packets to the VPN client named "VPNClient".
>
> Point 1) is about the server standard routing table while 2) is about
>
> the OpenVPN internal routing table.
>
> Both points can be achieved by means of OpenVPN configuration.
> 3.  add the following directive to your server config:
>
> route-ipv6 2a02:111::1::/64
> 4.  add the following directive to the CCD file (check
>
> --client-config-dir in the manpage) specific for the client serving this
>
> subnet:
>
> iroute-ipv6 2a02:111::1::/64
>
> At this point the OpenVPN server has an idea where to send packets when
>
> they have a dst IP belonging to that subnet.
>
> > Even if I try to add a static route for the network on the VPN server it 
> > does not go into the tunnel interface:
> >
> > ip -6 r a 2a02:111::1::/64 via 2a02:111::333::1000
>
> It seems you were trying to achieve almost what I explained above :-)
>
> For what concerns the "way out" (i.e. sending packets from the LAN
>
> behind BR0 towards the Internet), you just have to make sure that
>
> VPNClient is doing proper routing, but I believe it is, otherwise other
>
> things would break.
>
> Please let us know if this helps!
>
> Cheers,
>
>
> --
>
> Antonio Quartulli


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users