site-to-site, cannot ping from one lan to other lan

[A Former User]

sorry made mistake on the packet capture, that was from server, not client hang on.

[A Former User]

i tried a few times, the packets captured is blank

[Konstanti]

@asdffdsa6131
Host 10.0.0.4 not rebooted ?
Check if there is a route to 192.168 in its routing table

[A Former User]

Host 10.0.0.4 not rebooted ?
--- not rebooted
Check if there is a route to 192.168 in its routing table
--- i checked a few times, each time I try to re-add the rule I get the following error
C:\Users\user01>route add 192.168.62.0 mask 255.255.255.0 10.0.0.7
The route addition failed: The object already exists.

[Konstanti]

@asdffdsa6131
Good
Let's try another way
Ping 192.168.62.181->10.0.0.4 (or 10.0.0.1 or any other host from 10.0.0.0/24)
on the client side
Firewall/NAT Outbound/Edit (manual outbound)

If everything is configured correctly, then in packet capture (client side) you will see
10.0.0.7 ->10.0.0.4
10.0.0.4 ->10.0.0.7

[A Former User]

Ping 192.168.62.181->10.0.0.4
--- I have a continous ping going all the time.

Ping 192.168.62.181->10.0.0.4 continues to fail
ping 192.168.62.181 -> 10.0.0.1 also fails.

does this have something to do with that the client is an azure virtual machine and has no lan interface, just a wan interface?

[Konstanti]

@asdffdsa6131

NAT OUTBOUND changes the sender address (192.168.62.181) to its network address in the WAN interface (10.0.0.7) .the capture and package should show this
for example
IP 10.0.0.7 > 10.0.0.4: ICMP echo request, id 1, seq 16028, length 40
IP 10.0.0.7 > 10.0.0.4: ICMP echo request, id 1, seq 16029, length 40

[A Former User]

not sure what you are asking, sorry

[Konstanti]

@asdffdsa6131
192.168.62.181 -> 10.0.0.7 (nat outbound) -> 10.0.0.4 ->10.0.0.7 -> 192.168.62.181

In packet capture you should see instead of 192.168.62.181 10.0.0.7 (client side , wan interface)

[A Former User]

sorry, again I am not clear what you are asking for

[Konstanti]

@asdffdsa6131
NAT OUTBOUND changes the sender address (192.168.62.181) to its network address in the WAN interface (10.0.0.7) .the packet capture should show this (client side , wan interface)
for example
IP 10.0.0.7 > 10.0.0.4: ICMP echo request, id 1, seq 16028, length 40
IP 10.0.0.7 > 10.0.0.4: ICMP echo request, id 1, seq 16029, length 40

[A Former User]

I have to stop now, sorry,
I want to thank you much for you time.

we are missing something simple.
As far as I can tell, all the settings are correct on the sever and client.

I still think there is some issue with the fact the the client is in azure cloud and there is not lan interface, just a wan of 10.0.0.0/24.
good night,

[stephenw10]

Ok so there are two things and both were touched on.

By default pfSense NATs the traffic leaving the WAN but you probably don't want that. This is all private address space.

So go to the outbound NAT rules on the client end in Azure and remove them all. There should be NO NAT happening at that end.

Then the clients in Azure need a route back to 192.168.62.X. You tried to add that directly to the client, which should work, but you can also add that route in Azure so all clients there get routed to 10.0.0.7 for 192.168.62.X.

You will need firewall rules on the WAN to allow that traffic in.

You must also have enabled IP forwarding in Azure for the pfSense WAN NIC. Otherwise it will block traffic with destination 192.168.62.X as that does not exist on that VM:
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding

That may well be what was breaking this with NAT in place but it's better without NAT.

Steve

[A Former User]

@stephenw10
thanks much, I will try your suggestions.

it seems to me that traffic has to leave the azure pfsense via the wan, as that is the only interface, there is on lan interface.

you wrote "Then the clients in Azure need a route back to 192.168.62.X. You tried to add that directly to the client", do i add the route via the openvpn client or on each and every virtual computer via command line route.exe?

please consider updating the documentation, to deal with pfsense in the cloud, azure and aws.

I have spend days on this, working with a very knowledgeable forum people and nobody seems to know what to do with pfsense in cloud.

[stephenw10]

It's the Windows clients in Azure that need the route. That can either be added on each client or you can add it to the Azure routing for your VPC (or whatever Azure are naming the local subnet there). That will then apply to traffic from any client that hits the Azure gateway.

You can assign the OpenVPN interface there to get an additional logical interface. Because it would be the second interface it will appear as LAN which might make things even more confusing! WAN and LAN are just names though.

Steve