• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Problem with ping

Scheduled Pinned Locked Moved IPsec
3 Posts 3 Posters 887 Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M
    mbertei
    last edited by Oct 28, 2016, 9:52 AM

    Hi All, I've a 2 node Ipsec site to site VPN installation with 2 2.1.4-RELEASE (i386) PfSense, Node A and Node B.

    I've the follow problem:

    if I send from any pc behind node A a ping to any pc behind node B, I recieved a response.

    if I send from any pc behind node B a ping to any pc behind node A, I don't recieved a response.

    Node B(public IP ..94.153 - LAN IP 172.16.0.190 ) to A(public IP ..94.152 - LAN IP 192.168.111.10)
    No firewall active on any pc

    I collected these data:

    From Node A to B (It Works)

    WAN
    11:22:37.388235 IP ..94.152 > ..94.153: ESP(spi=0x0f7a5e0f,seq=0x4ab), length 104
    11:22:37.388698 IP ..94.153 > ..94.152: ESP(spi=0x09a0b256,seq=0x7f0), length 104
    11:22:37.996815 IP ..94.152 > ..94.153: ESP(spi=0x0f7a5e0f,seq=0x4ac), length 152
    11:22:37.999886 IP ..94.153 > ..94.152: ESP(spi=0x09a0b256,seq=0x7f1), length 152

    IPSEC
    11:23:54.377521 (authentic,confidential): SPI 0x0f7a5e0f: IP 192.168.111.10 > 172.16.0.190: ICMP echo request, id 1, seq 1906, length 40
    11:23:54.378142 (authentic,confidential): SPI 0x09a0b256: IP 172.16.0.190 > 192.168.111.10: ICMP echo reply, id 1, seq 1906, length 40
    11:23:55.391594 (authentic,confidential): SPI 0x0f7a5e0f: IP 192.168.111.10 > 172.16.0.190: ICMP echo request, id 1, seq 1907, length 40
    11:23:55.392077 (authentic,confidential): SPI 0x09a0b256: IP 172.16.0.190 > 192.168.111.10: ICMP echo reply, id 1, seq 1907, length 40

    LAN
    11:25:02.318437 IP 192.168.111.10 > 172.16.0.190: ICMP echo request, id 1, seq 1973, length 40
    11:25:02.318875 IP 172.16.0.190 > 192.168.111.10: ICMP echo reply, id 1, seq 1973, length 40
    11:25:03.332457 IP 192.168.111.10 > 172.16.0.190: ICMP echo request, id 1, seq 1974, length 40
    11:25:03.332867 IP 172.16.0.190 > 192.168.111.10: ICMP echo reply, id 1, seq 1974, length 40

    From Node B to A (It dosen't Works)

    Wan
    11:17:45.556447 IP ..94.153 > ..94.152: ESP(spi=0x09a0b256,seq=0x786), length 104
    11:17:50.556281 IP ..94.153 > ..94.152: ESP(spi=0x09a0b256,seq=0x787), length 104
    11:17:55.557365 IP ..94.153 > ..94.152: ESP(spi=0x09a0b256,seq=0x788), length 104

    Ipsec
    11:18:55.557563 (authentic,confidential): SPI 0x09a0b256: IP 172.16.0.190 > 192.168.111.10: ICMP echo request, id 1, seq 831, length 40
    11:19:00.556879 (authentic,confidential): SPI 0x09a0b256: IP 172.16.0.190 > 192.168.111.10: ICMP echo request, id 1, seq 832, length 40
    11:19:05.557712 (authentic,confidential): SPI 0x09a0b256: IP 172.16.0.190 > 192.168.111.10: ICMP echo request, id 1, seq 833, length 40

    Lan
    nothing….......... no ping

    I'm going crazy, I do not understand where I'm wrong :D :(

    do you have any idea? some configuration that I don't know I don't know...

    Thanks

    1 Reply Last reply Reply Quote 0
    • L
      luckman212 LAYER 8
      last edited by Nov 5, 2016, 4:42 AM

      @mbertei:

      Node B(public IP ..94.153 […] to A(public IP ..94.152

      Are those public IPs really "one off" from each other?  It seems then that they would be part of the same subnet?? hard to route between 2 IPs that are on the same subnet…something doesn't seem right.  But it is very late here and could be I am over tired and not understanding....  :o

      1 Reply Last reply Reply Quote 0
      • D
        Derelict LAYER 8 Netgate
        last edited by Nov 5, 2016, 6:12 AM

        2.1.4? Upgrade and ask again.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
          This community forum collects and processes your personal information.
          consent.not_received