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



  • hi to all and thanks for reading this,
    in my home lan, I have netgate sg100 and the pfsense is running in azure cloud.

    from the server/negate.sg110 web interface I can ping virtual computers behind the azure.pfsense
    from the azure.pfsense.client web interface, I can ping physical computers behind my netgate sg1110.

    however,
    I cannot ping from a physical computer behind my netgate to a virtual computer behind the azure pfsense
    I cannot ping from a virtual computer behind azure pfsense to a physical computer behind my netgate.sg1110

    I thought that since I had added the correct "IPv4 Remote network" on the server and client, that I should be able to ping from computer to computer.

    Do I need a add a manual route somehow and if so, how might I do that?
    or what do you suggest?

    thanks very much,
    david


  • LAYER 8 Rebel Alliance

    Show both sides OpenVPN and firewall settings (screenshots).

    -Rico



  • 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.
    0_1551039175863_7b570691-9118-4383-bf70-55e79b3b6335-image.png
    0_1551039203865_5e870c38-9bd1-4bbd-bf77-9b19f001d21b-image.png
    0_1551039267290_d1b478fc-7d1b-4fc4-bac1-7e63ab5e6109-image.png
    0_1551039391083_345955c8-10a0-46a6-b5e4-ea141db517a2-image.png

    from azure pfsense openvpn client
    0_1551039431923_55f85afd-0890-4708-b847-43534a1e4733-image.png
    0_1551039450556_e884e6f9-61bb-426b-bf6e-061c03c11bd7-image.png
    0_1551039513686_f231adab-f568-4beb-9601-f1cb221797ce-image.png
    0_1551039547048_ccaf2fe4-fbb2-402c-a681-ab157bfaf81b-image.png
    0_1551039577091_379f385f-c285-48a2-9ffb-46a55ac0698c-image.png



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

    Check 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
    0_1551042256031_b691261c-a9ce-41c3-b274-983f59e00d9c-image.png
    and here are the rules for the lan interface of the openvpn server
    0_1551042298102_76dcfdaa-33b9-4693-9aa9-ce22445307ca-image.png

    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/24

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

    0_1551043554856_75b89b9c-5563-429f-8e56-5f921c8c8983-image.png

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

    2 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

    0_1551045285954_ee6a2146-e192-4b1e-9c41-9696b8f5d7c1-image.png



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

    If 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
    0_1551046014656_63952d70-241c-4be7-b734-dc71f7e39b83-image.png

    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

    0_1551046402857_50d8e7a9-724b-4e42-aed4-3c306b8fffa7-image.png



  • @asdffdsa6131

    1. 10.0.0.7 already knows about this network
      0_1551046307753_1b7cad08-5ae7-4f73-80e1-cf16e971e152-image.png

    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

    1. on host 10.0.0.4, run the route add command ( see previous post)
    2. 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/24

    https://forum.netgate.com/topic/140925/site-to-site-cannot-ping-from-one-lan-to-other-lan/17



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

    0_1551047356628_12f59c89-b642-4194-bdbf-3809f59ecddd-image.png
    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 1

    IPv4 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 266

    Persistent Routes:
    None

    IPv6 Route Table

    Active Routes:
    If Metric Network Destination Gateway
    1 331 ::1/128 On-link
    1 331 ff00::/8 On-link

    Persistent 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
    0_1551048928252_d553ef14-0f5b-449a-bd0d-09c2b6214446-image.png

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


Log in to reply