Hi, On Wed, May 05, 2021 at 11:28:13AM +0200, Bo Berglund wrote: > >> server 10.8.113.0 255.255.255.0 'nopool' > >> ifconfig-pool 10.8.113.2 10.8.113.127 255.255.255.0 > > > >This is a bit weird. "server" *without* "nopool" will include the > >pool setting (though for the full /24)... so this is more complicated > >then necessary. > > What I am trying to do here is to separate external server devices from > external > clients. The external servers are remote monitoring RaspberryPi devices which > will sit behind non-public IP 4G routers. When they connect I want to set them > up to get a specific tunnel IP address via the ccd mechanism. So each such VPN > client will have an entry in the ccd dir. Therefore I have set aside half of > the > IP range for them.
Yeah, this is a valid argument.
[..]
> >> ifconfig-pool-persist ippagi.txt
> >> client-config-dir /etc/openvpn/ccdagi #Used to handle special configs
> >> # Add route to Client routing table for the OpenVPN Server
> >> push "route 10.8.113.1 255.255.255.255"
> >> # Add route to Client routing table for the OpenVPN Subnet
> >> push "route 10.8.113.0 255.255.255.0"
> >
> >This is not needed. The "server" subnet is always known.
>
> So if a Windows client connects to this VPN then it will automatically be able
> to reach 10.8.113.1 as well as the external servers on 10.8.113.xx addresses?
> That is *without* the added route pushes?
"Yes and no", to be precise.
If you use "topology subnet" - which is recommended - then every connecting
OpenVPN client will "see" the tunnel as "a flat /24". So, routing info is
there.
If you use "topology net30" - which is still the default, because changing
defaults is hard - every client gets its own /30, and I'm not sure if the
server will actually push a /24 route. But it will also waste addresses.
So, go for "topology subnet" and without pushed extra routes - they won't
do harm, but cause some noise in the client logs.
[..]
> >> So I don't want the tunnel clients to be routed out onto the server side
> >> LAN nor
> >> do I want them to be able to route through to the Internet.
> >> Basically the ONLY traffic in the tunnel should be the client-to-client
> >> traffic.
> >>
> >> What else should I do in the conf file?
> >
> >If the client is well-behaved, what you have is sufficient.
> >
> >If the client is malicious, it could just add "route" statements to
> >the local client conf and send packets your way. To prevent that, put
> >an iptables rule on the server tun interface and drop packets "coming
> >in via tun, to go out to the internet".
> >
> Well our client app used for configuration purposes is sending/receiving
> TCP/IP
> packets via the socket which are just ASCII with some telegram delimiters.
I was more thinking about "if someobody malicous lays their hand on such
an openvpn client config" - then you might want to do extra precautions
on the server to stop them from reaching "anything that is not on the VPN".
If it's all under your control, then the setup above is good enough.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
