Any idea what could be causing this weird routing issue?



  • Wasn't sure if this should be posted in Firewall or Routing as not sure where the problem is coming from.

    From the LAN:

    #host thenvm.org
    thenvm.org has address 198.49.23.145
    thenvm.org has address 198.185.159.145
    thenvm.org has address 198.49.23.144
    thenvm.org has address 198.185.159.144
    thenvm.org has address 162.255.119.210
    thenvm.org mail is handled by 5 alt1.aspmx.l.google.com.
    thenvm.org mail is handled by 5 alt2.aspmx.l.google.com.
    thenvm.org mail is handled by 10 aspmx2.googlemail.com.
    thenvm.org mail is handled by 10 aspmx3.googlemail.com.
    thenvm.org mail is handled by 1 aspmx.l.google.com.
    
    traceroute to thenvm.org (198.49.23.145), 30 hops max, 60 byte packets
     1  Router.lan (192.168.1.254)  0.295 ms  0.265 ms  0.239 ms
    

    From pfSense:

    traceroute to thenvm.org (198.49.23.145), 64 hops max, 40 byte packets
     1  lo1.subs.bng1.wh-man.zen.net.uk (62.3.89.162)  19.571 ms  19.596 ms  19.479 ms
     2  ae5-161.cr2.wh-man.zen.net.uk (62.3.86.13)  19.710 ms  19.921 ms  19.718 ms
     3  ae3-0.cr2.th-lon.zen.net.uk (62.3.80.58)  26.974 ms  26.926 ms  27.212 ms
     4  5.57.81.220 (5.57.81.220)  28.596 ms  28.583 ms  28.471 ms
     5  po111.bs-b.sech-lon2.netarch.akamai.com (72.52.60.202)  27.472 ms  27.902 ms  27.475 ms
     6  ae120.access-a.sech-lon2.netarch.akamai.com (72.52.60.197)  31.093 ms
        ae121.access-a.sech-lon2.netarch.akamai.com (72.52.60.205)  33.411 ms  36.169 ms
     7  93.191.173.69 (93.191.173.69)  113.506 ms
        93.191.173.11 (93.191.173.11)  103.153 ms  144.543 ms
     8  * * *
     9  198.49.23.145 (198.49.23.145)  131.293 ms  139.052 ms  133.193 ms
    

    Is this what would happen if that IP address is in one of the pfBlockerNG blocklists, or a routing problem? If its the blocklist does anyone know how I can find out which one?

    I'm not using DNS blocklists, just firewalling.



  • Hello @Alex-Atkin-UK,

    i don't understand what exactly is your problem? Please help me.


  • Rebel Alliance Global Moderator

    Yeah not understanding your problem either.. From your lan yes the first hop would be pfsense lan IP.. From pfsense first hop would be your ISP router, ie pfsense gateway on its wan.

    Are you saying the trace from lan stops there? The next hop should be your isp, etc.. The trace should show something..



  • That is the COMPLETE trace, its stopping at the router as if that is the destination.

    Just turned on all logging for pfBlockerNG and it does seem to be getting blocked there.

    pfB_Level1 auto rule (1770009609)
    

    I was just puzzled as I thought the traceroute would stall rather than just stop.

    For reference its in the Firehol level 1 list. Sorry for wasting anyones time.


  • Rebel Alliance Global Moderator

    I would of thought the trace would of continued as well.. Should of gotten a timeout on 2nd hop, 3rd, etc..

    Is the rule sending a reject? Or just dropping, ie blocked..

    I put a rule on wan outbound to block 8.8.8.8 did a trace from clients on lan

    user@uc:~$ traceroute 8.8.8.8
    traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
     1  sg4860.wlan.local.lan (192.168.2.253)  0.565 ms  0.264 ms  0.231 ms
     2  * * *
     3  * * *
     4  * * *
     5  * * *
    

    If you block on lan for 8.8.8.8, you don't even get a return for hop 1... But still does the same thing it times out for the rest of the hops.

    set to reject on floating tap I get this

    user@uc:~$ traceroute 8.8.8.8
    traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
     1  sg4860.wlan.local.lan (192.168.2.253)  0.542 ms  0.499 ms  0.411 ms
     2  sg4860.wlan.local.lan (192.168.2.253)  0.402 ms  0.308 ms  0.322 ms
    

    stops...

    What are the specifics of the rule, on the lan side of pfsense? On floating outbound stopping?

    Ok yeah reject as rule does do exactly what you are seeing when reject rule placed on the lan side.

    user@uc:~$ traceroute 8.8.8.8
    traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
     1  sg4860.wlan.local.lan (192.168.2.253)  0.824 ms  0.746 ms  0.700 ms
    user@uc:~$ 
    

    But on a windows client it continues to go..

    C:\>tracert -d 8.8.8.8
    
    Tracing route to 8.8.8.8 over a maximum of 30 hops
    
      1     *        *        *     Request timed out.
      2     *        *        *     Request timed out.
    


  • List Action: Deny Both
    States Removal: Enable

    LAN rule shows Reject but WAN rule shows Block.