site-to-site, cannot ping from one lan to other lan
-
hi rico, and thanks.
also, from the sg1110, i can ping 10.0.0.7, which is the ip address of the azure openvpn client's lan side ipaddress.
and from the azure openvpn client, I can ping 192.168.62.1, which is sg1100 server's ip address on its lan side.this is from the netgate sg1110 openvpn server, which I am really liking.
from azure pfsense openvpn client
-
@asdffdsa6131
Hey
Try to check the rules on the WAN interface OPENVPN client. They are configured to only allow traffic for 10.0.0.7 .
And show rules for Lan interface of OpenVPN serverCheck the firewall logs (status/system logs/Firewall) on both sides
Are there any blocked packets? -
Konstanti, thanks for the fast reply.
here are the rules for wan interface of the openvpn client
and here are the rules for the lan interface of the openvpn server
I am confused as I think the values for IPv4 Remote network(s) for both server and client are correct.
thanks so much
-
@asdffdsa6131
The problem , I think, is not routing
According to the routing tables, it seems that everything is correct
Look at the firewall logs on the Openvpn client side -
thanks, I tried I cannot find where to look for the logs for the firewall.
and should I do someting like a continuous ping from the a computer on the server side to a computer on the client side, so as to trigger someting useful in the firewall logs?
again thanks -
@asdffdsa6131
What is host 10.0.0.1 ??
How to set up routing from virtual machines ?
They know, that network 192.168.62.0 / 24 need to seek through 10.0.0.7 ?
And on wan interface 10.0.0.7 you need allow traffic to 192.168.62.0/24I think you should do this.
1 configure static routes on virtual machines for network 192.168.62.0 / 24 through 10.0.0.7
2. create rules on wan interface 10.0.0.7 to allow traffic for network 192.168.62.0 / 24 -
thanks, this is not making sense, as I am no expert in linux and new to pfsense but all the settings look correct, the openvpn server settings, the openvpn client settings, the firewalls and routes.
but what has me confused is that the pfsense server in azure, only has a single interface of WAN, but there is not a lan interface. for me that makes no sense and is confusing.
10.0.0.1, that is the default gateway for my azure virtual machines
here is the ipconfig /all from a windows.10 virtual machine
Ethernet adapter HyperV:
Connection-specific DNS Suffix . : llb4b2ht4myejjazjx4yah4a0c.bx.internal.cloudapp.net
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 00-0D-3A-1C-73-51
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.0.0.4(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Thursday, February 21, 2019 2:46:26 PM
Lease Expires . . . . . . . . . . : Wednesday, April 2, 2155 10:51:01 PM
Default Gateway . . . . . . . . . : 10.0.0.1
DHCP Server . . . . . . . . . . . : 168.63.129.16
DNS Servers . . . . . . . . . . . : 168.63.129.16
NetBIOS over Tcpip. . . . . . . . : Enabled -
@asdffdsa6131
As far as I understand , now PFSense - an internal host in a network 10.0.0.0/24 on which port 1194 from the main router is forwarded . Right ?I think you should do this.
1 configure static routes on virtual machines for network 192.168.62.0 / 24 through 10.0.0.72 create rules on wan interface 10.0.0.7 to allow traffic for network 192.168.62.0 / 24
-
@konstanti hi there,
correct, pfsense server is an internal host of 10.0.0.0/24 and its ip address is 10.0.0.7
and from my computer, 192.168.62.181, behind the sg1110, I can ping 10.0.0.7. -
ok. can you please be a little more specific as to what needs to be done on the openvpn server and openvpn client.
I am new to linux, pfsense and azure, I have been many days getting this far and I am growing from the experience.
I am not asking you for exactly what needs to be done, in 100% detail but a more detailed outline?
thanks again. -
@asdffdsa6131
This is easily explained, it is a feature of PFSense, an icmp packet that has passed through The OpenVPN client interface rule , is considered good and it is not blocked . But you can not ping , for example, 10.0.0.4 from your local computer , because the computer 10.0.0.4 knows nothing about the network 192.168. and sends the answer to 10.0.0.1 ( if you create the NAT OUTBOUND rule on the wan interface 10.0.0.7 for the network 192.168 , you can ping the entire network 10.0.0.0/24.
And in the opposite direction there is no (10.0.0.0 - >192.168.)
As much as I did , I wrote above
1 static routes
2 an allow rule for the network 192.168 on the WAN interface 10.0.0.7 -
ok. i will work on that thanks much
-
@asdffdsa6131
what is the guest operating system on the virtual machines ? For example, 10.0.0.4 ? -
ms.windows.10
-
@asdffdsa6131
1.From windows cli
route add 192.168.62.0 mask 255.255.255.0 10.0.0.7
2 Create an allow rule for the network 192.168 on the WAN interface 10.0.0.7 -
newbie question, on 10.0.0.7, the openvpn client, the outbound nat rule mode is automatic outbound nat rule generation and there is no option for adding rules, but I can add a mapping.
should I add a mapping or do I need to change the outbound nat mode? -
@asdffdsa6131
Do not create a NAT OUTBOUND rule yet
Try to do as I wrote in the previous postIf I understand everything correctly, you will be able to ping 10.0.0.4 from a network 192.168.62.0 / 24 and Vice versa
-
on the openvpn client, I did
on 10.0.0.7, the openvpn client, the outbound nat rule mode is automatic outbound nat rule generation and there is no option for adding rules, but I can add a mapping.
should I add a mapping or do I need to change the outbound nat mode? -
are you running a different version of pfsense, as your screenshot look visually different
-
@asdffdsa6131
- 10.0.0.7 already knows about this network
No need to create another static route on 10.0.0.7 for network 192.168.62.0 / 24
Don't need to configure OUTBOUND NAT now
Need to, for example- on host 10.0.0.4, run the route add command ( see previous post)
- create allow rule (see previous post)
Then you can ping the host 10.0.0.4 from the network 192.168.62.0/24
and the host 10.0.0.4 will be able to ping the network 192.168.62.0/24https://forum.netgate.com/topic/140925/site-to-site-cannot-ping-from-one-lan-to-other-lan/17
- 10.0.0.7 already knows about this network
-
thanks but i added the firewall rule in openvpn client and the route add 192.168.62.0 mask 255.255.255.0 10.0.0.7 on 10.0.0.4
but no pinging.
and added the "route add 192.168.62.0 mask 255.255.255.0 10.0.0.7"C:\Users\user01>route print
Interface List
7...00 0d 3a 1c 73 51 ......Microsoft Hyper-V Network Adapter
8...00 ff e3 05 f1 eb ......TAP-ProtonVPN Windows Adapter V9
6...00 ff d6 ca 59 0c ......TAP-Windows Adapter V9
1...........................Software Loopback Interface 1IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.4 10
10.0.0.0 255.255.255.0 On-link 10.0.0.4 266
10.0.0.4 255.255.255.255 On-link 10.0.0.4 266
10.0.0.255 255.255.255.255 On-link 10.0.0.4 266
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
168.63.129.16 255.255.255.255 10.0.0.1 10.0.0.4 11
169.254.169.254 255.255.255.255 10.0.0.1 10.0.0.4 11
192.168.62.0 255.255.255.0 10.0.0.7 10.0.0.4 11
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.0.0.4 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.0.0.4 266Persistent Routes:
NoneIPv6 Route Table
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
1 331 ff00::/8 On-linkPersistent Routes:
None -
@asdffdsa6131
Hmmm.
Let's check.
I see that packets went in the direction 192.168.62.0/24
Check to see if the numbers appear in this place ?
This is a rule on the OpenVpn server interface
Can host 10.0.0.4 ping 192.168.62.1 ?
Can host 192.168.62.1 ping 10.0.0.4 ? -
hi again,
I have a continuous ping from 10.0.0.4 to 192.168.62.1 and it is 'request time out' -
@asdffdsa6131
On the Openvpn server side
In WEBGUI
/Diagnostics/Packet Capture /
Interface Openvpn
Protocol ICMP
Startwhat is the result ?
-
thank much,
18:05:09.356421 IP 192.168.62.181 > 10.0.0.4: ICMP echo request, id 1, seq 15875, length 40
18:05:11.355996 IP 192.168.62.181 > 10.0.0.4: ICMP echo request, id 1, seq 15876, length 40
18:05:13.344929 IP 192.168.62.181 > 10.0.0.4: ICMP echo request, id 1, seq 15877, length 40 -
@asdffdsa6131
Now the same is on the Openvpn client side
WAN interface only
we continue to ping 192.168.62.181 > 10.0.0.4 -
192.168.62.181 is my windows 10 laptop
-
openvpn client side, wan interface only
18:10:15.358365 IP 192.168.62.181 > 10.0.0.4: ICMP echo request, id 1, seq 16028, length 40
18:10:17.360473 IP 192.168.62.181 > 10.0.0.4: ICMP echo request, id 1, seq 16029, length 40 -
@asdffdsa6131
We can see that the tunnel is working
but the host 10.0.0.4 does not respond to pings
Can host 192.168.62.181 ping 10.0.0.7 ?
If you run ping 10.0.0.4 ->192.168.62.181 (or 192.168.62.1)
What will packet capture show ? -
We can see that the tunnel is working
--- correct
but the host 10.0.0.4 does not respond to pings
--- correct
Can host 192.168.62.181 ping 10.0.0.7 ?
--- I tried again and the answer is no
If you run ping 10.0.0.4 ->192.168.62.181
--- I have a continous ping from 10.0.0.4 -> 192.168.62.181
What will packet capture show ?
--- If you mean on the openvpn client
18:22:40.814131 IP 40.97.154.82.443 > 47.20.7.132.20255: tcp 43
18:22:40.866569 IP 47.20.7.132.20255 > 40.97.154.82.443: tcp 0
18:22:41.070851 IP 47.20.7.132 > 47.20.4.1: ICMP echo request, id 16129, seq 7040, length 8
18:22:41.077374 IP 47.20.4.1 > 47.20.7.132: ICMP echo reply, id 16129, seq 7040, length 8
18:22:41.567306 IP 40.85.175.163.443 > 47.20.7.132.40913: tcp 51
18:22:41.603084 IP 47.20.7.132 > 47.20.4.1: ICMP echo request, id 16129, seq 7041, length 8
18:22:41.609795 IP 47.20.4.1 > 47.20.7.132: ICMP echo reply, id 16129, seq 7041, length 8
18:22:41.617013 IP 47.20.7.132.40913 > 40.85.175.163.443: tcp 0
18:22:42.132944 IP 47.20.7.132 > 47.20.4.1: ICMP echo request, id 16129, seq 7042, length 8
18:22:42.142050 IP 47.20.4.1 > 47.20.7.132: ICMP echo reply, id 16129, seq 7042, length 8
18:22:42.665103 IP 47.20.7.132 > 47.20.4.1: ICMP echo request, id 16129, seq 7043, length 8
18:22:42.668422 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.677302 IP 47.20.4.1 > 47.20.7.132: ICMP echo reply, id 16129, seq 7043, length 8
18:22:42.685356 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 0
18:22:42.685659 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.697633 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 517
18:22:42.716822 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 0
18:22:42.731861 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.737668 IP 47.20.7.132.10038 > 23.10.93.204.443: tcp 226
18:22:42.738583 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.738726 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.738752 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.738881 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.738907 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 521
18:22:42.738942 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.739068 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.739089 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.741041 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 126
18:22:42.743358 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 0
18:22:42.743432 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.743650 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 311
18:22:42.754079 IP 23.10.93.204.443 > 47.20.7.132.10038: tcp 128
18:22:42.754123 IP 23.10.93.204.443 > 47.20.7.132.10038: tcp 38
18:22:42.756267 IP 47.20.7.132.10038 > 23.10.93.204.443: tcp 0
18:22:42.756930 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 0
18:22:42.757434 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 1460
18:22:42.757472 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.757482 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 1242
18:22:42.757509 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.758787 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 51
18:22:42.759295 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 242
18:22:42.769256 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 126
18:22:42.779281 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 424
18:22:42.779366 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.779793 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 86
18:22:42.790808 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 499
18:22:42.790873 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.791582 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 31
18:22:42.791901 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.797959 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 356
18:22:42.800224 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 0
18:22:42.800262 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 0
18:22:42.800644 IP 1.1.1.1.853 > 47.20.7.132.37964: tcp 0
18:22:42.800689 IP 47.20.7.132.37964 > 1.1.1.1.853: tcp 0
18:22:42.829447 IP 40.97.228.178.443 > 47.20.7.132.30169: tcp 43
18:22:42.837753 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.894908 IP 47.20.7.132.30169 > 40.97.228.178.443: tcp 0
18:22:42.993896 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.993988 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 927
18:22:42.994014 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.994147 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.994179 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 646
18:22:42.994202 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.994226 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.994250 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.994274 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 365
18:22:42.994295 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:42.994447 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.994468 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.994489 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.994516 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.994536 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:42.994662 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.011965 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.011992 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.012016 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.012277 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.012297 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.012316 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.017503 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.017529 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.017785 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.017823 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.017843 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.017850 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.017978 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018004 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018040 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.018151 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018190 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.018197 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018220 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018244 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018280 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.018406 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.018413 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018437 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460
18:22:43.018473 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.018493 IP 47.20.7.132.4987 > 38.27.106.14.443: tcp 0
18:22:43.018609 IP 38.27.106.14.443 > 47.20.7.132.4987: tcp 1460 -
sorry made mistake on the packet capture, that was from server, not client hang on.
-
i tried a few times, the packets captured is blank
-
@asdffdsa6131
Host 10.0.0.4 not rebooted ?
Check if there is a route to 192.168 in its routing table -
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. -
@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 -
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?
-
@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 -
not sure what you are asking, sorry
-
@asdffdsa6131
192.168.62.181 -> 10.0.0.7 (nat outbound) -> 10.0.0.4 ->10.0.0.7 -> 192.168.62.181In packet capture you should see instead of 192.168.62.181 10.0.0.7 (client side , wan interface)
-
sorry, again I am not clear what you are asking for