Site-to-site

johnied

Also when I run both site-to-site VPN connections, where in the first:
A router is server, B router is client.
And in the second(which was created for testing):
A router is client, B router is server.

Both routers behave the same. I can ping from vpn interfaces to the others LAN, but not from their LAN interfaces to the other LAN.

viragomann

@johnied:

What do you mean? I perform ICMP Diagnostics->Packet Capture on the one router,and Diagnostics->Ping on the other router from the interfaces I describe in the header of every capture.

On which interface have you taken the capture? VPN?

@johnied:

Something that occured to me: Both VPN interfaces (server and client) are using LAN as interface. Does this pose any threat?

???
@johnied:

CLIENT VPN INT to SERVER VPN INT:
20:16:08.987196 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 0, length 64
20:16:08.987779 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 0, length 64
20:16:10.045360 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 38425, seq 1, length 64
20:16:10.045857 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 38425, seq 1, length 64

This shows the client vpn ip pinging to a servers LAN device.

The same as here:
@johnied:

CLIENT VPN INT to SERVER LAN INT:
20:17:30.889581 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
20:17:30.889655 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192
20:17:33.177124 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 0, length 64
20:17:33.177610 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 0, length 64
20:17:34.236385 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 1, length 64
20:17:34.236938 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 1, length 64
20:17:35.297149 IP 10.5.0.2 > 192.168.1.201: ICMP echo request, id 46688, seq 2, length 64
20:17:35.298138 IP 192.168.1.201 > 10.5.0.2: ICMP echo reply, id 46688, seq 2, length 64
20:17:35.957371 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 156, seq 0, length 192
20:17:35.957446 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 156, seq 0, length 192

Obviously taken on the servers LAN interface. I wonder why 192.168.1.2 is pinging the LAN at the same time.

johnied

Obviously taken on the servers LAN interface. I wonder why 192.168.1.2 is pinging the LAN at the same time.

192.168.1.2 is just a wifi Access Point which checks if it has access to the gateway. It's not important. I should not have posted it.

On which interface have you taken the capture? VPN?

Both VPN interfaces and LAN interfaces. I clarify it in the line before the capture logs every time.

This shows the client vpn ip pinging to a servers LAN device.

Yes, because I don't get any packets captured when I am pinging from the LAN interface.
I only capture packets, when I am pinging from the VPN interface.
And only from the client router.

From the Server I can't ping from LAN or VPN interface. Both fail.

johnied

Ok, I think I am close to my goal.
I dismissed the idea of Peer to Peer(SSL/TLS) and went on to create a Peer to Peer(Shared Key) connection.

Now I can ping from the Client LAN to the Server lan flawlessly.

What I cant't do is ping from the Server LAN to the client LAN.

I packet captured the client lan interface when ping from server lan interface and although I see the packet requests, there is no reply.

The client packet capture logs on the LAN interface read:

01:07:48.438501 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 0, length 64
01:07:49.432827 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 1, length 64
01:07:50.434429 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 2, length 64

and I am attaching the server ping procedure that had the above as a result.

This must be a NAT issue isn't that right?

![Server Ping.png](/public/imported_attachments/1/Server Ping.png)
![Server Ping.png_thumb](/public/imported_attachments/1/Server Ping.png_thumb)

johnied

I can ping from Server LAN only the Client's LAN IP.
I cannot ping any other device on the Network.

Since Client's router is not the gateway of the whole network yes, I tried adding an Outbound NAT rule like the image attached.

No luck however.

If the client VPN is running on a Wan interface and not on a LAN, should the NAT rule use the WAN or the LAN interface?

![NAT rule client.png](/public/imported_attachments/1/NAT rule client.png)
![NAT rule client.png_thumb](/public/imported_attachments/1/NAT rule client.png_thumb)

Derelict

I dismissed the idea of Peer to Peer(SSL/TLS) and went on to create a Peer to Peer(Shared Key) connection.

Now I can ping from the Client LAN to the Server lan flawlessly.

This is because you had the tunnel network as a /24.

When you have an SSL/TLS OpenVPN server with a larger than /30 (or is it /29?) tunnel network it will be treated as a point-to-multipoint server instead of point-to-point. You must add the remote network to the server configuration, which creates the kernel route (OpenVPN route directive) into OpenVPN. You must also create a client-specific override and add the network to the Remote Networks which creates a route internal to OpenVPN (OpenVPN iroute directive) so OpenVPN knows which endpoint to send the traffic to. You must do this even if there is only one available endpoint. If you do not want to have to do this, make the tunnel network a /30.

The client packet capture logs on the LAN interface read:

01:07:48.438501 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 0, length 64
01:07:49.432827 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 1, length 64
01:07:50.434429 IP 192.168.1.1 > 192.168.0.201: ICMP echo request, id 9946, seq 2, length 64

If that can ping the other way that is almost always the local firewall/antivirus/etc on the target that is 192.168.0.201. pfSense can't do much but send the request (which it is doing) and wait for the reply (which never comes).

johnied

If that can ping the other way that is almost always the local firewall/antivirus/etc on the target that is 192.168.0.201. pfSense can't do much but send the request (which it is doing) and wait for the reply (which never comes).

Reply never comes when I ping from server's LAN interface.
It replies normally when I ping from server's VPN interface.

Derelict

Great. So check the firewall/antivirus/etc on 192.168.0.201. It looks like it is blocking pings.

johnied

I don't understand.

192.168.0.201 is on the client's network.
I checked and the firewall is off.
So when I ping from the server's LAN interface it is not responding.
When I ping from the server's VPN interface it responds normally.

The client's router is not the main gateway of the client's network yet. I tried NATing the whole network but it does not work.

NATing the network works only for the VPN server on the client's computer which is for remote administration only(not site-to-site).

Should I add a static route to the specific PC(192.168.0.201) till I make the pfsense router the default gateway?

Derelict

In the packet capture you can see the echo request leaving the Client LAN interface addressed to 192.168.0.201 and nothing coming back. The problem is somewhere outside of pfSense.

Yes, pfSense has to be the gateway for the target device or you need to add a route on that host for the far side of the VPN tunnel with a gateway that is pfSense or the replies will be sent to the wrong place.

Alternately you can place an outbound NAT rule on the client LAN interface so traffic sourced from the remote VPN network is NATted to the interface address there. Then replies will be same-subnet so the route will not be necessary.