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 msFrom 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 msIs 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.
-
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.
-
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 msstops...
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: EnableLAN rule shows Reject but WAN rule shows Block.
