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



  • 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
    Start

    what 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
    0_1551050555319_1edae2e8-a18b-4057-a39c-6189c875867f-image.png


    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.



  • 0_1551050748859_1e0bf7a3-af7e-4f7c-984a-21828c6e6cc2-image.png

    i tried a few times, the packets captured is blank
    0_1551050831032_e5c3e602-cbce-4212-943f-d765e21a47d8-image.png



  • @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)
    0_1551051478768_9c094fbe-a5dc-4d38-9a83-bb3c52a79253-image.png

    0_1551051457167_47e98eeb-0674-41e2-abbb-4de552166e83-image.png

    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.
    0_1551051884275_28f05316-1590-488c-bc56-06a6ff3a362b-image.png

    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.181

    In 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



  • @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



  • 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,


  • Netgate Administrator

    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



  • @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.


  • Netgate Administrator

    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


Log in to reply