OpenVPN refinements

[Hans-Peter Jansen]

Hi,

I try to tighten a OpenVPN setup.

It should result in a separate zone for tun0 (10.20.30.0/24), that allows ssh 
on the local net, which is in the external zone otherwise (192.168.78.0/24).

$ firewall-cmd --info-zone=external
external (active)
  target: DROP
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: dhcpv6-client http https ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

$ firewall-cmd --info-zone=internal
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: tun0
  sources: 
  services: ssh
  ports:
  protocols: 
  masquerade: no
  forward-ports:
  source-ports: 
  icmp-blocks: 
  rich rules: 
        rule family="ipv4" source address="10.20.30.0/24" destination 
address="192.168.78.0/24" port port="8080" protocol="tcp" accept

Hence, it should allow routing ssh requests to eth0.

All experiments result in IN_external_DROPs, because this is defined as 
external, I guess.

Yes, I know, this setup is rather improper. It's a transient state on the way 
to proper separate internal and external network interfaces.

Any idea, how to archive this?

Thanks in advance,
Pete

[Eric Garver]

I'm not certain what you're trying to accomplish.

Are you trying to allow SSH access to the OpenVPN server?

Your rich rule is using port 8080. Are you trying to forward 8080 to ssh
(22)?

Are you trying to allow SSH access to a machine on the internal network
that in behind the OpenVPN server?

On Thu, Mar 19, 2020 at 07:40:13PM +0100, Hans-Peter Jansen wrote:
> Hi,
>
> I try to tighten a OpenVPN setup.
>
> It should result in a separate zone for tun0 (10.20.30.0/24), that allows ssh 
> on the local net, which is in the external zone otherwise (192.168.78.0/24).
>
> $ firewall-cmd --info-zone=external
> external (active)
>   target: DROP
>   icmp-block-inversion: no
>   interfaces: eth0
>   sources: 
>   services: dhcpv6-client http https ssh
>   ports: 
>   protocols: 
>   masquerade: no
>   forward-ports: 
>   source-ports: 
>   icmp-blocks: 
>   rich rules:
>
> $ firewall-cmd --info-zone=internal
> internal (active)
>   target: default
>   icmp-block-inversion: no
>   interfaces: tun0
>   sources: 
>   services: ssh
>   ports:
>   protocols: 
>   masquerade: no
>   forward-ports:
>   source-ports: 
>   icmp-blocks: 
>   rich rules: 
>         rule family="ipv4" source address="10.20.30.0/24" destination 
> address="192.168.78.0/24" port port="8080" protocol="tcp" accept
>
> Hence, it should allow routing ssh requests to eth0.
>
> All experiments result in IN_external_DROPs, because this is defined as 
> external, I guess.
>
> Yes, I know, this setup is rather improper. It's a transient state on the way 
> to proper separate internal and external network interfaces.
>
> Any idea, how to archive this?
>
> Thanks in advance,
> Pete
>
> firewalld-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...

[Hans-Peter Jansen]

Am Donnerstag, 19. März 2020, 20:06:19 CET schrieb Eric Garver:
> I'm not certain what you're trying to accomplish.

Sorry, Eric, for my deficits in expressing my needs.
> Are you trying to allow SSH access to the OpenVPN server?

This is working fine.
> Your rich rule is using port 8080. Are you trying to forward 8080 to ssh
> (22)?

Hrmpf. I've tried to eliminate all disturbing elements, but failed.
Yes, a service on port 8080 needs be allowed as well, but having it working 
for ssh is enough to get the rest working in a similar fashion.

It should have read:
        rule family="ipv4" source address="10.20.30.0/24" destination 
 address="192.168.78.0/24" port port="22" protocol="tcp" accept

I've tried port forwarding and other things, but ultimately, I would like to 
allow some services coming from the VPN (tun0/10.20.30.0/24) to be routed to 
the local network (and back).
> Are you trying to allow SSH access to a machine on the internal network
> that in behind the OpenVPN server?

Yes, exactly. Routing is activated, but there's some interference of routing, 
masquerading and iptables rules, I'm unable to grok completely..

Thanks,
Pete
> On Thu, Mar 19, 2020 at 07:40:13PM +0100, Hans-Peter Jansen wrote:
> > Hi,
> >
> > I try to tighten a OpenVPN setup.
> >
> > It should result in a separate zone for tun0 (10.20.30.0/24), that allows
> > ssh on the local net, which is in the external zone otherwise
> > (192.168.78.0/24). 
> > $ firewall-cmd --info-zone=external
> > external (active)
> >
> > target: DROP
> >   icmp-block-inversion: no
> >   interfaces: eth0
> >   sources: 
> >   services: dhcpv6-client http https ssh
> >   ports: 
> >   protocols: 
> >   masquerade: no
> >   forward-ports: 
> >   source-ports: 
> >   icmp-blocks: 
> >   rich rules:
> >
> > $ firewall-cmd --info-zone=internal
> > internal (active)
> >
> > target: default
> >   icmp-block-inversion: no
> >   interfaces: tun0
> >   sources: 
> >   services: ssh
> >   ports:
> >   protocols: 
> >   masquerade: no
> >   forward-ports:
> >   source-ports: 
> >   icmp-blocks: 
> >   rich rules:
> >     rule family="ipv4" source address="10.20.30.0/24" destination 
> >
> > address="192.168.78.0/24" port port="8080" protocol="tcp" accept
> >
> > Hence, it should allow routing ssh requests to eth0.
> >
> > All experiments result in IN_external_DROPs, because this is defined as 
> > external, I guess.
> >
> > Yes, I know, this setup is rather improper. It's a transient state on the
> > way

to proper separate internal and external network interfaces.
> > Any idea, how to archive this?
> >
> > Thanks in advance,
> > Pete
> >
> > firewalld-users mailing list -- [e-mail]
> > To unsubscribe send an email to
> > [e-mail]

Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> > Archives:
> > https://lists.fedorahosted.org/archives/list/[e-mail]
> > hosted.org
>
> firewalld-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]
> sted.org

[Eric Garver]

On Fri, Mar 20, 2020 at 08:39:36AM +0100, Hans-Peter Jansen wrote:
> Am Donnerstag, 19. März 2020, 20:06:19 CET schrieb Eric Garver:
> > I'm not certain what you're trying to accomplish.
>
> Sorry, Eric, for my deficits in expressing my needs.
> > Are you trying to allow SSH access to the OpenVPN server?
>
> This is working fine.
> > Your rich rule is using port 8080. Are you trying to forward 8080 to ssh
> > (22)?
>
> Hrmpf. I've tried to eliminate all disturbing elements, but failed.
> Yes, a service on port 8080 needs be allowed as well, but having it working 
> for ssh is enough to get the rest working in a similar fashion.
>
> It should have read:
>         rule family="ipv4" source address="10.20.30.0/24" destination 
>  address="192.168.78.0/24" port port="22" protocol="tcp" accept
>
> I've tried port forwarding and other things, but ultimately, I would like to 
> allow some services coming from the VPN (tun0/10.20.30.0/24) to be routed to 
> the local network (and back).

On the client side is your SSH destination in the 10.20.30.0/24 block of
addresses or are you using the OpenVPN's "uplink" address (eth0) ?

[..]

[Hans-Peter Jansen]

Am Freitag, 20. März 2020, 20:12:03 CET schrieb Eric Garver:
> On Fri, Mar 20, 2020 at 08:39:36AM +0100, Hans-Peter Jansen wrote:
> > Am Donnerstag, 19. März 2020, 20:06:19 CET schrieb Eric Garver:
> >
> > Hrmpf. I've tried to eliminate all disturbing elements, but failed.
> > Yes, a service on port 8080 needs be allowed as well, but having it
> > working for ssh is enough to get the rest working in a similar fashion.
> >
> > It should have read:
> >     rule family="ipv4" source address="10.20.30.0/24" destination 
> >
> > address="192.168.78.0/24" port port="22" protocol="tcp" accept
> >
> > I've tried port forwarding and other things, but ultimately, I would like
> > to allow some services coming from the VPN (tun0/10.20.30.0/24) to be
> > routed to the local network (and back).
>
> On the client side is your SSH destination in the 10.20.30.0/24 block of
> addresses or are you using the OpenVPN's "uplink" address (eth0) ?

They come in from the VPN block 10.20.30.0/24.

[Eric Garver]

On Fri, Mar 20, 2020 at 09:23:45PM +0100, Hans-Peter Jansen wrote:
> Am Freitag, 20. März 2020, 20:12:03 CET schrieb Eric Garver:
> > On Fri, Mar 20, 2020 at 08:39:36AM +0100, Hans-Peter Jansen wrote:
> > > Am Donnerstag, 19. März 2020, 20:06:19 CET schrieb Eric Garver:
> > >
> > > Hrmpf. I've tried to eliminate all disturbing elements, but failed.
> > > Yes, a service on port 8080 needs be allowed as well, but having it
> > > working for ssh is enough to get the rest working in a similar fashion.
> > >
> > > It should have read:
> > >     rule family="ipv4" source address="10.20.30.0/24" destination 
> > >
> > > address="192.168.78.0/24" port port="22" protocol="tcp" accept
> > >
> > > I've tried port forwarding and other things, but ultimately, I would like
> > > to allow some services coming from the VPN (tun0/10.20.30.0/24) to be
> > > routed to the local network (and back).
> >
> > On the client side is your SSH destination in the 10.20.30.0/24 block of
> > addresses or are you using the OpenVPN's "uplink" address (eth0) ?
>
> They come in from the VPN block 10.20.30.0/24.

Does the VPN work at all? Can an external client communicate with a
internal client? AFAICS, the OpenVPN traffic will be denied at the
external zone. You haven't added the openvpn service.

Maybe try

firewall-cmd --zone external --add-service openvpn

The stock service only allows UDP. If you're using TCP backed OpenVPN
(you shouldn't) then you need to allow it explicitly:

firewall-cmd --zone external --add-port=1194/tcp

[Hans-Peter Jansen]

Am Freitag, 20. März 2020, 21:44:10 CET schrieb Eric Garver:
> On Fri, Mar 20, 2020 at 09:23:45PM +0100, Hans-Peter Jansen wrote:
> > Am Freitag, 20. März 2020, 20:12:03 CET schrieb Eric Garver:
> > > On Fri, Mar 20, 2020 at 08:39:36AM +0100, Hans-Peter Jansen wrote:
> > > > Am Donnerstag, 19. März 2020, 20:06:19 CET schrieb Eric Garver:
> > > >
> > > > Hrmpf. I've tried to eliminate all disturbing elements, but failed.
> > > > Yes, a service on port 8080 needs be allowed as well, but having it
> > > > working for ssh is enough to get the rest working in a similar
> > > > fashion.
> > > >
> > > > It should have read:
> > > >     rule family="ipv4" source address="10.20.30.0/24" destination
> > > >
> > > >
> > > >
> > > > address="192.168.78.0/24" port port="22" protocol="tcp" accept
> > > >
> > > > I've tried port forwarding and other things, but ultimately, I would
> > > > like
> > > > to allow some services coming from the VPN (tun0/10.20.30.0/24) to be
> > > > routed to the local network (and back).
> > >
> > > On the client side is your SSH destination in the 10.20.30.0/24 block
> > > of
> > > addresses or are you using the OpenVPN's "uplink" address (eth0) ?
> >
> > They come in from the VPN block 10.20.30.0/24.
>
> Does the VPN work at all? Can an external client communicate with a
> internal client? AFAICS, the OpenVPN traffic will be denied at the
> external zone. You haven't added the openvpn service.
>
> Maybe try
> firewall-cmd --zone external --add-service openvpn
>
> The stock service only allows UDP. If you're using TCP backed OpenVPN
> (you shouldn't) then you need to allow it explicitly:
> firewall-cmd --zone external --add-port=1194/tcp

Yes, sorry again for the omission. Yes, I've opened the external openvpn port 
and using vpn server services including ssh are working fine. It's just the 
routing to the local net part, that is dysfunctional, although these are 
outgoing from the vpn serverpoint of view (but departing from the wrong net).

Thanks,
Pete

[Eric Garver]

On Sat, Mar 21, 2020 at 11:13:31AM +0100, Hans-Peter Jansen wrote:
> Am Freitag, 20. März 2020, 21:44:10 CET schrieb Eric Garver:
> > On Fri, Mar 20, 2020 at 09:23:45PM +0100, Hans-Peter Jansen wrote:
> > > Am Freitag, 20. März 2020, 20:12:03 CET schrieb Eric Garver:
> > > > On Fri, Mar 20, 2020 at 08:39:36AM +0100, Hans-Peter Jansen wrote:
> > > > > Am Donnerstag, 19. März 2020, 20:06:19 CET schrieb Eric Garver:
> > > > >
> > > > > Hrmpf. I've tried to eliminate all disturbing elements, but failed.
> > > > > Yes, a service on port 8080 needs be allowed as well, but having it
> > > > > working for ssh is enough to get the rest working in a similar
> > > > > fashion.
> > > > >
> > > > > It should have read:
> > > > >     rule family="ipv4" source address="10.20.30.0/24" destination
> > > > >
> > > > >
> > > > >
> > > > > address="192.168.78.0/24" port port="22" protocol="tcp" accept
> > > > >
> > > > > I've tried port forwarding and other things, but ultimately, I would
> > > > > like
> > > > > to allow some services coming from the VPN (tun0/10.20.30.0/24) to be
> > > > > routed to the local network (and back).
> > > >
> > > > On the client side is your SSH destination in the 10.20.30.0/24 block
> > > > of
> > > > addresses or are you using the OpenVPN's "uplink" address (eth0) ?
> > >
> > > They come in from the VPN block 10.20.30.0/24.
> >
> > Does the VPN work at all? Can an external client communicate with a
> > internal client? AFAICS, the OpenVPN traffic will be denied at the
> > external zone. You haven't added the openvpn service.
> >
> > Maybe try
> > firewall-cmd --zone external --add-service openvpn
> >
> > The stock service only allows UDP. If you're using TCP backed OpenVPN
> > (you shouldn't) then you need to allow it explicitly:
> > firewall-cmd --zone external --add-port=1194/tcp
>
> Yes, sorry again for the omission. Yes, I've opened the external openvpn port 
> and using vpn server services including ssh are working fine. It's just the 
> routing to the local net part, that is dysfunctional, although these are 
> outgoing from the vpn serverpoint of view (but departing from the wrong net).

I think you're actually experience routing issues. Not firewall issues.

Getting the routing correct will be tricky. The OpenVPN server needs to
have forwarding enabled:

openvpn-server # sysctl -w net.ipv4.conf.all.forwarding=1

With that hopefully the OpenVPN server will forwarding from the VPN
tunnel to the node behind the server (internal network).

But the node on the internal network also needs a route for the tunnel
network, e.g. 10.20.30.0/24. This destination should be the OpenVPN
server.

internal-client # ip route add 10.20.30.0/24 nexthop \
                        via <openvpn-server IP> \
                        dev <lan_dev>

It may take some debugging (tcpdump/wireshark) to figure out where the
traffic is getting lost.

You may also encounter issues with IPv4 rp_filter. Check the sysctls on
the OpenVPN server and internal client.

Hopefully that points you in the right direction.
Eric.