Messages

1

20.1 Legacy Series / Re: OpenVPN site2site no routing back to client

« on: March 24, 2020, 01:31:54 pm »

Hold up.

SO I followed the guide here: https://docs.opnsense.org/manual/how-tos/sslvpn_s2s.html
the laptop can happily route through the asus, that is the default gw, to the 172.16 network

But things in the 172 network cannot route through to the 10.0 network.

Whilst the asus is just terrible the above also suggests that site b is configured as a "client".
This could just be a matter of terminology though really.

The asus does also have "server" options but they are limited, eg , not actual tunnel network just local and remote address opts

2

20.1 Legacy Series / Re: OpenVPN site2site no routing back to client

« on: March 24, 2020, 11:58:06 am »

rofl while that would maybe be nice I'm not sure that generally it would magically fix the routing issue.

3

20.1 Legacy Series / Re: OpenVPN site2site no routing back to client

« on: March 24, 2020, 11:32:20 am »

To me this pcap looks "correct", which is to say that the traffic is going to the OpenVPN interface but ...

ovpns2    11:15:44.611790 IP 172.16.1.0 > 10.0.100.175: ICMP echo request, id 21954, seq 528, length 64
ovpns2   1 1:15:45.635887 IP 172.16.1.0 > 10.0.100.175: ICMP echo request, id 21954, seq 529, length 64
ovpns2   11:15:46.659833 IP 172.16.1.0 > 10.0.100.175: ICMP echo request, id 21954, seq 530, length 64

LAN
vmx2   11:15:44.611781 IP 172.16.1.0 > 10.0.100.175: ICMP echo request, id 21954, seq 528, length 64
LAN
vmx2   11:15:45.635859 IP 172.16.1.0 > 10.0.100.175: ICMP echo request, id 21954, seq 529, length 64
LAN
vmx2   11:15:46.190199 IP 172.16.1.0.68 > 172.16.0.1.67: UDP, length 277
LAN
vmx2   11:15:46.191298 IP 172.16.0.1.67 > 172.16.1.0.68: UDP, length 328
LAN
vmx2   11:15:46.659816 IP 172.16.1.0 > 10.0.100.175: ICMP echo request, id 21954, seq 530, length 64


So back to routing problem

4

20.1 Legacy Series / Re: OpenVPN site2site no routing back to client

« on: March 24, 2020, 11:04:18 am »

@chemlud: OpenVPN FW rules are just ... horribly open at this point, attached.

@banym: It is the default gateway (unless I've really lost my mind) at least for the LAN behind it.
Here is a ... truly awful network diagram though

It doesn't seem so much like a firewalling/filtering problem rn, packages just do not seem to be routed from the OPNsense to the tunnel (see traceroute pics). But I am going to run some package captures now.

5

20.1 Legacy Series / OpenVPN site2site no routing back to client

« on: March 24, 2020, 09:28:40 am »

SO the first ... caveat is the client end of this VPN is commercial HW, specifically an asus ac88u running merlin 384.15 though I do not think this should matter.


I have defined a peer-to-peer TLS OpenVPN server in opnsense with the following:
Server Mode: Peer to Peer (SSL/TLS)
Protocol: TCP
Device mode: TUN
interface: WAN
Port: 8080

Crypto Settings as per https://docs.opnsense.org/manual/how-tos/sslvpn_s2s.html
(created CA etc etc)

IPv4 Tunnel Network: 192.168.254.0/29
Local Network: 172.16.0.0/20
Remote Network: 10.0.0.0/16

Address Pool is checked which I believe was on by default.

Allowed incoming on the wan interface to that port (8080)
Rules:OpenVPN has all allowed.

Exporting the config and loading it to the asus is fine.
Tunnel is up. Can ping from remote to OPNsense LAN.

But I cannot route BACK to the asus network and I really believe that it appears to be an issue on the OPNsense side of this.

In the web gui the routes are there and look ok to me.
attachment1.jpg

In console the routes are also visible and look good:
attachment2.jpg

Traceroute from console though does NOT show traffic going down the tunnel:
attachment3.jpg


Is routing not actually my problem here? Do I need to add some firewall rules? I don't SEE any blocked traffic in the Firewall:LogFiles:LiveView

From the console I can ping both sides of the tunnel network (192.168.254.1 and 192.168.254.6)
From a client machine in the OPNsense LAN I can also ping both ends of the tunnel Network. But when I try to send traffic to the otherside it goes ... nowhere.

Am I going crazy here? Were should I be hunting logs to figure this out?