Routing issues after Upgrade (2.4.4) - No (ICMP) Reply to packets



  • Hello,

    its seems i messed up somehow after upgrading to 2.4.4_2.

    Im trying to reach: 10.55.101.21 (LAN Network) from openvpn Network (10.0.8.3)

    Using Diagnostics Ping it works fine from LAN Interface.
    LAN -> LAN 10.55.101.21 -> ok

    Using Diagnostics Ping from OPENVPN Interface
    GCAccessVPN -> LAN 10.55.101.21 -> no

    Rules are set to any/any on both interfaces. Everything is open.

    If I do Packet Capturing: I see the ECHO but no REPLY.

    Any suggestions?



  • Additional Information, which makes curious.

    LAN Interface rules:
    0_1552297788914_8b5b3eb2-fa95-4350-bf5f-24620facd703-grafik.png

    but are blocked?
    0_1552297693154_c86321c2-f887-4561-b170-03f6b3f18bfe-grafik.png

    In addition to that:
    Only DNS request are send thru the connection:
    0_1552297890857_0d10e89e-c6ce-441b-b22e-f4180aa458d2-grafik.png

    Anyone an Idea, what I have to check?


  • LAYER 8 Global Moderator

    You seem to have asymmetrical routing..

    The devices on your "lan" actually use pfsense as their default gateway?

    You see those SA - tells me psense seeing the Syn,Ack (answer to syn in opening connection) but never saw the syn to open the state.

    Could you draw up this network.



  • Like this? - It is virtualized on VMware ESXi 6.5
    0_1552302184167_5914eee0-3f73-4518-93d2-077255265eec-grafik.png


  • LAYER 8 Global Moderator

    Ok that looks pretty sane.

    So all the devices have default gateway as the IP address of pfsense in these /24s

    This is sign of out of state traffic
    0_1552302181643_outofstate.png

    10.55.101.247 sent syn,ack to 10.55.102.41 and to .32 but got blocked because no state would be the reason SA normally blocked.

    Normally means that 101.247 got the syn without it going through pfsense so it could set up the state.. Running multiple L3 networks on the same L2 could do that. Since your saying this is VM, need to see the configuration of your vswitching.. Are you doing port groups. Is pfsense VM as well? Are you letting pfsense handle the tags for the vlans? Etc. etc..

    You say you sniffed and saw the echo request.. Where did you sniff.. If you sniffed on pfsense interface into the network, then pfsense did its job and sent the request, if you don't see a reply - the box either sent it to some other gateway, didn't answer, never got it, etc.



  • Got you... but I wasn't finish yet :-)

    the FW works with CARP IP (HA). The CARP IP is set a default GW for the clients. Maybe thats the reason for this asymmetrical rounting?
    0_1552302523073_7f347192-39d2-4a4f-8327-5b7af6d81bbc-grafik.png

    Well..
    PING from VPN Client captured on FW
    0_1552302941819_e1c149ac-ce13-4410-ac56-bc8dc1336d7c-grafik.png

    Ping direct FW -> Server
    0_1552303101650_d808e119-931b-4eb7-bb1d-b263615bcd8b-grafik.png

    Ping VPN Interface -> Server
    0_1552303124876_76d2232b-cf7d-4aca-a5b7-35dff6bf4905-grafik.png
    0_1552303147154_945a4e6e-665e-48a0-9f80-862f4b54e335-grafik.png


  • LAYER 8 Global Moderator

    Yeah carp could have to do with it for sure..

    You sure your HA is working correctly.. If you send the syn,ack back or echo reply back to wrong pfsense then yeah you have the same sort of issue.



  • Holy shit... it seems to be something bigger...

    FW1
    0_1552304373550_c5ba27cd-9a99-4355-90f8-0eeeb9affa6b-grafik.png

    FW2
    0_1552304339549_1b2b8ec2-99e9-4712-9e43-ad5d519fa4ba-grafik.png

    I only saw "The system is on the latest version"....
    Well now i have to check, why the update didn't work and it doesn't see the missing updates....



  • Ok. HA is back and online... but the initial issue still exists :-(

    Nothing arrives at .102
    0_1552309912945_f07ab6d7-d8ce-4f9e-912b-1b502c959599-grafik.png


Log in to reply