New ISP, port forwarding working intermittently



  • Previously on CenturyLink gigabit fiber. DHCP WAN with PPPoE auth. pfsense was acting as modem. All port forwarding working perfectly.

    Now on Whidbey Telecom DSL. Static WAN IP. They have a mandatory modem that they claim is just a passthrough with no filtering when it has a static IP but my port forwarding now doesn't work. Or rather, I don't believe that traffic is reaching me.

    Happy to post exhaustive configurations if necessary but I first want to make sure that my test procedure is correct here.

    1. I start a packet capture on the WAN interface for traffic with host <WAN IP> and port 80
    2. I load up the dynamic firewall logs page and filter by destination IP <WAN IP> and destination port 80
    3. I load <WAN IP>:80 on my phone (with WiFi disconnected) and wait

    When doing the above, I see no relevant results.

    Is there any other local configuration problem that could cause incoming traffic never to hit the firewall or the packet capture? Or is there a more canonical way to test this?

    As I said, this configuration worked perfectly for years on my previous ISP and doesn't on this one so I really feel like it's upstream from me but they insist that no filtering is occurring on their modem or on any of their equipment upstream.

    Thank you! Please let me know if there is anything else I can post that would be helpful. Not sure where to start exactly.



  • Yeah it was definitely something on their end. A tech just came by for an unrelated reason (to bond my DSL line and increase my bandwidth) and as part of that process, he gave me a different modem and now it works. ¯_(ツ)_/¯



  • Well that was short-lived. Overnight port forwarding stopped working again... Any ideas of where to start troubleshooting this?



  • I think your ISP needs to troubleshoot...

    -Rico



  • Haha fair enough. I agree. Can you think of a more convincing test setup to help me show them that the problem is not by firewall?


  • Rebel Alliance Global Moderator

    is it really a modem? Or is it a gateway - does your pfsense get a public IP on its wan or a rfc1918 address.

    Many an ISP block inbound server ports like 80/443/21/22 etc.. You know for the safety of their customers ;)

    If your not seeing the inbound traffic to pfsense wan IP and this IP is public - then its your isp blocking it, something upstream of pfsense - or you trying to go to the wrong IP.

    I ask this because the days of true DSL modems is way behind us, and most all devices supplied by isp in the last what 10 years that I have seen have all been gateways. Ie a combo device of the modem and a nat router. If your pfsense is getting a rfc1918 IP then the device is gateway doing nat - or your behind a carrier grade nat.. With a nat router you can forward traffic to pfsense for pfsense to forward. Or put it into bridge/modem mode. But if your behind a carrier grade nat - good luck.



  • Good clarification.

    • When it's in DHCP mode, the gateway is 192.168.2.1 (which loads the ISP device control panel in the browser) and my firewall gets a rfc1918 address.
    • When it's in static IP mode, my firewall gets a public IP and the gateway is another public IP.

    I'm in static IP mode now and definitely not double NATed.

    They claim not to block any ports and when it's working I can indeed use 80/442/21/etc but when it's not working I also can't even access other ports like 32400.


  • Rebel Alliance Global Moderator

    if pfsense has public IP, and you go to say canyouseeme org and test a port while your sniffing on pfsense wan and you do not see this traffic on the port your testing. Then the problem is upstream of pfsense, and nothing pfsense can do to fix that.



  • Okay, yeah that's what I'm experiencing and that was my conclusion as well. Just wanted to confirm that there was nothing else I could do in pfsense to prove to my ISP that the problem is upstream of me.

    Thank you!


  • Rebel Alliance Global Moderator

    Well the sniff will prove it too them..


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy