(SOLVED) Problem with client connect through static IP cable internet



  • @KOM said in Problem with client connect through static IP cable internet:

    Nobody wants to parse through an XML file. Screencaps are much better, a picture worth a thousand words etc.

    I am sorry but I am not on-premise. I only have the config here. But I'll try to create a VM, import the config and make screencaptures.





  • Get rid of that floating rule. You don't need it and it may be part of the problem. If you lose connectivity after deleting that rule then there is a deeper problem to be discovered and fixed because, like I said earlier, floating rules are used for QoS and special custom configs. You don't need any floating rules to get basic connectivity working.

    Your LAN rules look good but there is no traffic logged (0/0 B for each rule) which means pfSense isn't seeing anything from LAN that is hitting those rules. The floating rule may be taking precedence.

    What specific errors are the clients getting when trying to connect using various things like ssh or http/s? The exact error text can be very helpful.



  • This post is deleted!


  • @KOM said in Problem with client connect through static IP cable internet:

    Get rid of that floating rule. You don't need it and it may be part of the problem. If you lose connectivity after deleting that rule then there is a deeper problem to be discovered and fixed because, like I said earlier, floating rules are used for QoS and special custom configs. You don't need any floating rules to get basic connectivity working.

    Your LAN rules look good but there is no traffic logged (0/0 B for each rule) which means pfSense isn't seeing anything from LAN that is hitting those rules. The floating rule may be taking precedence.

    What specific errors are the clients getting when trying to connect using various things like ssh or http/s? The exact error text can be very helpful.

    Just to be 100% clear on that: without the floating rule the clients are not able to access the internet. Even IP-based traffic (like ssh to an IP) is not possible without the floating rule. Pinging specific IPs works, everything else does not work.
    With the floating rule, the internet and everything else works just perfectly.

    It is 99% a firewall issue.

    My setup is a fresh install of pfSense with only the static IP for the WAN interface and the floating rule added.

    When the floating rule is NOT enabled: curl/ssh and everything like that simply times out. There are no specific error messages (only "Connecting to ....... Connection timed-out"). The error text is very non-descriptive.

    I will provide the exact error messages after I have pfSense installed freshly (without the floating rule).



  • The default LAN IPv4 allow to any rule does not belong on the floating, so something is wrong there.
    Do you have other Floating rules?



  • @maverickws said in Problem with client connect through static IP cable internet:

    The default LAN IPv4 allow to any rule does not belong on the floating, so something is wrong there.
    Do you have other Floating rules?

    The default "LAN IPv4 allow" rule is unchanged from a fresh install (and also works when using my DSL internet through PPPoE on the WAN interface). But when using the static IP configuration for WAN this rule (for some reason) does not work (0/0B)...

    This here is a screenshot of my DSL internet firewall rule (NOT the cable static-IP internet connection where the problem persists):
    0b84dfc5-1aa9-4301-b231-eed7646e23af.png
    In this configuration for DSL with PPPoE, I do NOT have a floating rule - everything works fine.


  • LAYER 8 Moderator

    @paprikawuerzung said in Problem with client connect through static IP cable internet:

    Just to be 100% clear on that: without the floating rule the clients are not able to access the internet. Even IP-based traffic (like ssh to an IP) is not possible without the floating rule. Pinging specific IPs works, everything else does not work.

    And to be clear on our side: a floating rule is NOT needed for proper functionality. IF things work only then, you have - as already said - a deeper problem or serious configuration flaw that you didn't see/show. As outbound rules are created automatically in the background, something definetly doesn't add up. Period.

    As debugging is simply voodoo and guessing at the moment, you should gather information when you are back on site and post them. Even screens in the VM are void, as it's not the same constellation as on site with the WAN and a LAN client behind it to test.

    I'd also double check DHCP settings and the client on premise: does it have the right IP address and does it match the LAN configuration? Not the first time there was a simple small problem in numbers that got switched around and as the default LAN rules are matched against "LAN net" instead of "any" a DHCP problem can go unnoticed as "firewall access works".
    Traceroute from the Client helps checking if the packet goes the right way and if and where it hits the firewall to trigger routes and rules.



  • @JeGr said in Problem with client connect through static IP cable internet:

    @paprikawuerzung said in Problem with client connect through static IP cable internet:

    Just to be 100% clear on that: without the floating rule the clients are not able to access the internet. Even IP-based traffic (like ssh to an IP) is not possible without the floating rule. Pinging specific IPs works, everything else does not work.

    And to be clear on our side: a floating rule is NOT needed for proper functionality. IF things work only then, you have - as already said - a deeper problem or serious configuration flaw that you didn't see/show. As outbound rules are created automatically in the background, something definetly doesn't add up. Period.

    Yes, sorry for my tone in the previous posts. I am a little frustrated that at first every post was about DNS and DHCP when I already ruled that out 10 posts ago (for that matter I was sure that its not a problem before I even posted this thread) and I wanted it to be clear that it really, really is not the problem at all.

    I know that you help me with your time and I am very grateful for that!

    To the topic:
    This is a complete fresh install with only the static IP and gateway for the WAN interface added. If it is a configuration problem it is part of pfSense as it (appearently) does NOT "create the outbound rules automatically in the background".
    Since there are no definitive guides on how to configure static WAN IP setups (with UnityMedia/KabelBW) it is highly unclear whether this calls for floating rules or not. I read the sections in the pfSense regarding floating rules and understand that they are only used as a last resort - and that internet normally works out of the box with everything handled perfectly by pfSense - but this is obviously not the case.

    As debugging is simply voodoo and guessing at the moment, you should gather information when you are back on site and post them. Even screens in the VM are void, as it's not the same constellation as on site with the WAN and a LAN client behind it to test.

    The configuration (down to the IP addresses) is exactly the same so it is not completely void.

    I'd also double check DHCP settings and the client on premise: does it have the right IP address and does it match the LAN configuration? Not the first time there was a simple small problem in numbers that got switched around and as the default LAN rules are matched against "LAN net" instead of "any" a DHCP problem can go unnoticed as "firewall access works".

    DHCP on client side works and the IPs, Gateway, Domain etc. are set correctly. I am very sure about that. It is not a configuration error in the DHCP area. Which also shows that when I add the floating rule (without re-requesting a DHCP lease) -> the internet works instantly - without any further configuration of the client or pfSense.

    Traceroute from the Client helps checking if the packet goes the right way and if and where it hits the firewall to trigger routes and rules.

    I will provide screenshots and outputs after I am at the premise again.

    A thousand thanks again for your answers/guidance!


  • LAYER 8 Moderator

    @paprikawuerzung said in Problem with client connect through static IP cable internet:

    as it (appearently) does NOT "create the outbound rules automatically in the background".

    Yes it is. In default configuration. Otherwise check /tmp/rules.debug for yourself and compare it with your DSL configuration.

    @paprikawuerzung said in Problem with client connect through static IP cable internet:

    Since there are no definitive guides on how to configure static WAN IP setups (with UnityMedia/KabelBW) it is highly unclear whether this calls for floating rules or not.

    Why should there? It's completely transparent. If you configure DHCP IP, static IP or PPPoE for exmaple don't matter at all what pfSense creates for automatic rules like automatic outbound rules, default LAN rules etc. It's essentially the same if you don't configure some highly experimental or advanced options on the Interfaces/WAN setup screen.

    and that internet normally works out of the box with everything handled perfectly by pfSense - but this is obviously not the case.

    Yes in your case. In hundreds of others we configured/installed it does. Be it PPPoE, DHCP, static IP4. No matter what :)

    The configuration (down to the IP addresses) is exactly the same so it is not completely void.

    Void for me as in "I can't help or debug with you when this is not the same environment the error happens and the virtual setup isn't configured exactly the same (as in: has some sort of uplink, a test VM as client behind it etc. etc.)". So for debugging the problem it's not really well suited :)



  • @JeGr said in Problem with client connect through static IP cable internet:

    @paprikawuerzung said in Problem with client connect through static IP cable internet:

    as it (appearently) does NOT "create the outbound rules automatically in the background".

    Yes it is. In default configuration. Otherwise check /tmp/rules.debug for yourself and compare it with your DSL configuration.

    It is a complete fresh install with no firewalls added and no additional configuration made apart from adding the static IP. Whether this rule is created or not (I believe you if you say it is) does not make any difference as it does not work.

    @paprikawuerzung said in Problem with client connect through static IP cable internet:

    Since there are no definitive guides on how to configure static WAN IP setups (with UnityMedia/KabelBW) it is highly unclear whether this calls for floating rules or not.

    Why should there? It's completely transparent. If you configure DHCP IP, static IP or PPPoE for exmaple don't matter at all what pfSense creates for automatic rules like automatic outbound rules, default LAN rules etc. It's essentially the same if you don't configure some highly experimental or advanced options on the Interfaces/WAN setup screen.

    and that internet normally works out of the box with everything handled perfectly by pfSense - but this is obviously not the case.

    Yes in your case. In hundreds of others we configured/installed it does. Be it PPPoE, DHCP, static IP4. No matter what :)

    I also configured the PPPoE configuration without any problems at all. The only difference here is that I add a static IP (provided by UM) and a gateway (also provided by UM). Why this should create problems with the firewall is beyond my knowledge...

    The configuration (down to the IP addresses) is exactly the same so it is not completely void.

    Void for me as in "I can't help or debug with you when this is not the same environment the error happens and the virtual setup isn't configured exactly the same (as in: has some sort of uplink, a test VM as client behind it etc. etc.)". So for debugging the problem it's not really well suited :)

    Ok. I will provide screenshots from the running system.



  • https://docs.netgate.com/pfsense/en/latest/routing/connectivity-troubleshooting.html

    It's always something from this list. I would do a packet capture on LAN to see if client packets are hitting the interface at all, and another on WAN to see if they're being forwarded out.



  • I fixed the error by adding a WAN firewall rule. In the default installation, this rule was missing:

    Screenshot_2019-07-05 pfSense office patagona de - Firewall Rules Edit.png

    I found the rule in another pfSense installation (= DSL internet) which I compared to the (now working) cable internet installation. After adding it, everything works just fine. The floating rule was overkill but essentially did the same thing.
    I am still a little confused why this rule was not created automatically (as it was in the PPPoE DSL installation). Also, there were strange issues when booting the Fritz!Box BEFORE booting pfSense - even with reboots. In the last installation, everything worked out just fine and with no hassle - strange, strange... But now everything seems to be working just as I want it to ๐Ÿ˜„

    Thousand thanks for your time and suggestions, @JeGr, @kiokoman, @KOM and @maverickws ! ๐Ÿ™‚



  • No, you still have a problem. You shouldn't have ANY rules on WAN except for Block RFC1918, and any port-forwards you have defined. You do NOT need a WAN rule to get Internet access from LAN. You have something weird going on with your installation or environment.



  • @KOM said in (SOLVED) Problem with client connect through static IP cable internet:

    No, you still have a problem. You shouldn't have ANY rules on WAN except for Block RFC1918, and any port-forwards you have defined. You do NOT need a WAN rule to get Internet access from LAN. You have something weird going on with your installation or environment.

    I am little frustrated by these comments suggesting the configuration is strange: my configuration (as I told at least 5 times) is done completely from a clean installation (factory reset on pfSense or even new installation). I only added (as I told at least 5 times) only the static IP (+ Gateway) given by UnityMedia and left everything apart from the (global) DNS servers (which arguably are really, really not the problem) as default.

    The Fritz!Box 6490 is factory reset (with IT'S public, static IP defined/put there by UnityMedia) and apart from disabling the WLAN, I did not change anything. This public, static IP defined in the Fritz!Box (and provided by UnityMedia) is my gateway in pfSense. This setup was suggested by three different technicians at UnityMedia and most likely is not the culprit.
    So, I would argue that my setup or configuration is not special in any strange way.



  • I am not sure whether this helps but this is the output of /tmp/rules.debug

    (My added rule is in there also)



  • Wait, you have Snort installed?? I assumed that you were using a default config to get it going without installing any extra packages. If that is the case, please disable ALL packages that may interfere with traffic, such as Snort, Suricata, pfBlocker, squidguard.



  • @paprikawuerzung said in (SOLVED) Problem with client connect through static IP cable internet:

    Fritz!Box 6490

    Your modem is a Puma 6 powered model and AFAIC a piece of crap. But my guess is that you are stuck with it. (badmodems.com)

    That model is a gateway model and is still routing as opposed to true bridge mode.

    How many static addresses did they give you? The /30 surprises me a little.



  • @KOM said in (SOLVED) Problem with client connect through static IP cable internet:

    Wait, you have Snort installed?? I assumed that you were using a default config to get it going without installing any extra packages. If that is the case, please disable ALL packages that may interfere with traffic, such as Snort, Suricata, pfBlocker, squidguard.

    I have nothing installed which is not in a fresh install. I added "OpenVPN Client Export" as a plugin just now - but apart from that I enabled/installed no package.



  • Oh OK. I saw references in the rules to snort2c sets and I jumped to conclusions. Those types of packages are notorious for causing LAN traffic problems when not configured properly. I'm not sure what else to add. It just works out of the box for literally thousands of people. Have you gone through the Connectivity guide I linked to step by step?

    Also, my suggestion for packet capture is still valid.



  • @chpalmer said in (SOLVED) Problem with client connect through static IP cable internet:

    @paprikawuerzung said in (SOLVED) Problem with client connect through static IP cable internet:

    Fritz!Box 6490

    Your modem is a Puma 6 powered model and AFAIC a piece of crap. But my guess is that you are stuck with it. (badmodems.com)

    That model is a gateway model and is still routing as opposed to true bridge mode.

    How many static addresses did they give you? The /30 surprises me a little.

    Hi @chpalmer: I have 1 static IP assigned by the ISP. The other IPs in the subnet are the network IP, broadcast and gateway (4 hosts per /30 subnet) as far as I know.



  • @KOM said in (SOLVED) Problem with client connect through static IP cable internet:

    Oh OK. I saw references in the rules to snort2c sets and I jumped to conclusions. Those types of packages are notorious for causing LAN traffic problems when not configured properly. I'm not sure what else to add. It just works out of the box for literally thousands of people. Have you gone through the Connectivity guide I linked to step by step?

    I have gone through the connectivity guide before, yes. The answers to all the questions in the troubleshooting guide are scattered through this thread.

    Also, my suggestion for packet capture is still valid.

    I am not exactly positive that this will add more to our understanding. The WAN firewall rule allowing traffic from the WAN to the LAN network "fixes" the problem.
    I guess my only question is: does this pose a security threat and how can I test it? If it does not create any further problems and does not compromise the security - I am really not that keen on investigating the problem further. Maybe it got anything to do with the ISP or a quirk of the modem or... or... or...



  • Yes, having a rule on WAN that allows all traffic to LAN is certainly not best practice. It allows access to WebGUI from WAN, for one thing. A packet capture would tell you if LAN is even seeing the traffic, and the WAN capture would show if it's leaving for the Internet.



  • @KOM said in (SOLVED) Problem with client connect through static IP cable internet:

    Yes, having a rule on WAN that allows all traffic to LAN is certainly not best practice. It allows access to WebGUI from WAN, for one thing. A packet capture would tell you if LAN is even seeing the traffic, and the WAN capture would show if it's leaving for the Internet.

    This is not a problem since pfSense is behind the gateway which in turn does not expose pfSense (and therefor the WebGUI is not seen) to the outside. I already did a full port scan with nmap on both the gateway and the pfSense IPs - no ports open (of course there are hidden ports - but no response from them).

    I assume that especially since the Fritz!Box 6490 Cable does not simply do bridging but instead also some routing/firewalling by itself, this setup is not more insecure than a normal Fritz!Box setup. But of course I am not entirely sure about that.

    I will try a packet capture tomorrow - but I strongly suspect that the packet leaves pfSense but the firewall blocks the response. Why it only does this when using TCP/UDP (layer-4) traffic and not ping is beyond my knowledge.
    I will provide the results tomorrow.


  • LAYER 8 Moderator

    @paprikawuerzung said in (SOLVED) Problem with client connect through static IP cable internet:

    this setup is not more insecure than a normal Fritz!Box setup. But of course I am not entirely sure about that.

    It is. You are passing all - ALL - TCP traffic from internet to your inside LAN without filtering. You could simply add any instead of TCP or remove pfsense alltogether as your solution is opening the firewall completely so you have no filtering at all. The whole (one of the) reason of a firewall is filtering what should and should not enter/leave your network. You are frustrated that it isn't working like it should in your mind. I can understand that. But your solution is no solution at all but to simply remove the firewall. Also being angry at us pointing out that in exactly default case it isn't necessary and should never be the solution to even add such a rule is understandable but not helpful to your case. If you had such a rule on DSL setup is even more astonishing as it's not necessary at all to even let something in on WAN if you have no services to reach via WAN (host your own website, NAS etc.). So besides ICMP which is arguable anything else on WAN should be default and block only.

    I'd take a hard look at tcpdump, the state table and outbound NAT to check how and what arrives on the outside of the internet. E.g.

    • do a curl ifconfig.me/ip on pfSense diagonstics/run command
    • activate your "solution" rule and do the same from a PC - you read the same IP?
    • if so, what's the IP on the WAN interface of pfSense (status/interfaces -> check WAN)
    • if your client PC works with that strange rule, surf to a specific site where you know its IP and then check Diagnostic/States and filter for the client PC's IP - there should be two states for the website your called, one on LAN, one on WAN with the outbound NATted IP in brackes (). Check that if that makes sense. If it has none pfSense is not NATting properly. Check again without your rule and after flushing states or giving the ruleset time to reload and the state to expire otherwise you could have the effect that it works without the rule because the state is still active.
    • also uncheck block bogons/private networks on WAN and check again if anything works without that pass any rule on WAN. Quite a few cable providers are using formerly unassigned IP space now and if pfSense hasn't refreshed the bogus list, it could be blocked because of that!

    It'd be possible that the strange setup with your cable box actually let's pfSense think it has another IP as it really has and for that matter NAT's to the wrong IP. Something like that. But hear us when we are trying to tell you: in no proper setup is there a need for a WAN to LAN pass any rule to exist. There definetly is something bogus going on.

    This is not a problem since pfSense is behind the gateway which in turn does not expose pfSense (and therefor the WebGUI is not seen) to the outside. I already did a full port scan with nmap on both the gateway and the pfSense IPs - no ports open (of course there are hidden ports - but no response from them).
    I assume that especially since the Fritz!Box 6490 Cable does not simply do bridging but instead also some routing/firewalling by itself, this setup is not more insecure than a normal Fritz!Box setup. But of course I am not entirely sure about that.

    And after the next provider driven update of your Fritz!Box, something changes, the bridging suddenly works and you are exposed to the internet. Want to bet on that? I wouldn't. Also that happened in southern Germany. Recent updates of cable provider's FBs suddenly activated the long lost bridging feature of the consumer boxes that hadn't worked before. Even if the ISP itself states, switching to bridging won't work as they have to do some internal magic, too, I wouldn't bet at that. A simple error in ISPs configuration could expose your whole network as in your setup the box shouldn't do routing at all but simply passing the IP to pfSense's WAN interface. That's a risk I wouldn't take.



  • @JeGr said in (SOLVED) Problem with client connect through static IP cable internet:

    @paprikawuerzung said in (SOLVED) Problem with client connect through static IP cable internet:

    this setup is not more insecure than a normal Fritz!Box setup. But of course I am not entirely sure about that.

    It is. You are passing all - ALL - TCP traffic from internet to your inside LAN without filtering. You could simply add any instead of TCP or remove pfsense alltogether as your solution is opening the firewall completely so you have no filtering at all. The whole (one of the) reason of a firewall is filtering what should and should not enter/leave your network. You are frustrated that it isn't working like it should in your mind. I can understand that. But your solution is no solution at all but to simply remove the firewall. Also being angry at us pointing out that in exactly default case it isn't necessary and should never be the solution to even add such a rule is understandable but not helpful to your case. If you had such a rule on DSL setup is even more astonishing as it's not necessary at all to even let something in on WAN if you have no services to reach via WAN (host your own website, NAS etc.). So besides ICMP which is arguable anything else on WAN should be default and block only.

    I'd take a hard look at tcpdump, the state table and outbound NAT to check how and what arrives on the outside of the internet. E.g.

    • do a curl ifconfig.me/ip on pfSense diagonstics/run command
    • activate your "solution" rule and do the same from a PC - you read the same IP?
    • if so, what's the IP on the WAN interface of pfSense (status/interfaces -> check WAN)
    • if your client PC works with that strange rule, surf to a specific site where you know its IP and then check Diagnostic/States and filter for the client PC's IP - there should be two states for the website your called, one on LAN, one on WAN with the outbound NATted IP in brackes (). Check that if that makes sense. If it has none pfSense is not NATting properly. Check again without your rule and after flushing states or giving the ruleset time to reload and the state to expire otherwise you could have the effect that it works without the rule because the state is still active.
    • also uncheck block bogons/private networks on WAN and check again if anything works without that pass any rule on WAN. Quite a few cable providers are using formerly unassigned IP space now and if pfSense hasn't refreshed the bogus list, it could be blocked because of that!

    It'd be possible that the strange setup with your cable box actually let's pfSense think it has another IP as it really has and for that matter NAT's to the wrong IP. Something like that. But hear us when we are trying to tell you: in no proper setup is there a need for a WAN to LAN pass any rule to exist. There definetly is something bogus going on.

    This is not a problem since pfSense is behind the gateway which in turn does not expose pfSense (and therefor the WebGUI is not seen) to the outside. I already did a full port scan with nmap on both the gateway and the pfSense IPs - no ports open (of course there are hidden ports - but no response from them).
    I assume that especially since the Fritz!Box 6490 Cable does not simply do bridging but instead also some routing/firewalling by itself, this setup is not more insecure than a normal Fritz!Box setup. But of course I am not entirely sure about that.

    And after the next provider driven update of your Fritz!Box, something changes, the bridging suddenly works and you are exposed to the internet. Want to bet on that? I wouldn't. Also that happened in southern Germany. Recent updates of cable provider's FBs suddenly activated the long lost bridging feature of the consumer boxes that hadn't worked before. Even if the ISP itself states, switching to bridging won't work as they have to do some internal magic, too, I wouldn't bet at that. A simple error in ISPs configuration could expose your whole network as in your setup the box shouldn't do routing at all but simply passing the IP to pfSense's WAN interface. That's a risk I wouldn't take.

    Ok, thanks a lot for your thorough explanation and sorry for the frustration I showed - I am very grateful for all your input/help!

    I will have to debug it more throughly and will post the results of it as soon as I do it. That said: I called UnityMedia because we do not just have this firewall problem but the Fritz!Box 6490 Cable itself seems to have problems with the speeds and a little load. It switches from 100Mbit on the LAN port (it should be 1000Mbit but this somehow does not work at all) to 10Mbit. Sometimes packets just get lost under load. The technician said that this most likely is due to a faulty Fritz!Box or some poor cabling in the building - which is somehow curious since the first Fritz!Box the technician installed was also faulty - he had to get a new one since it did not boot (maybe they are recycling old products?). The whole charade is deeply unsatisfactory... I switched to the Telekom DSL internet again - which works also through pfSense but with a bought modem - DrayTec Vigor 130 - absolutely no hassles there at all. The UnityMedia cable internet was only bought to temporarily have faster internet - we will get fibre internet in half a year or something. I am not sure how my experience relates to other customers but this is just.....

    But again - a thousand thanks, especially to you @JeGr, for helping me through this process! โ˜บ

    PS: I did the Telekom DSL configuration of pfSense from scratch again and saw that the WAN rule is indeed not needed. I only had an additional OpenVPN rule.


  • LAYER 8 Moderator

    @paprikawuerzung said in (SOLVED) Problem with client connect through static IP cable internet:

    It switches from 100Mbit on the LAN port (it should be 1000Mbit but this somehow does not work at all) to 10Mbit.

    Urgh, that sounds a lot like bad hardware. Never saw that behavior on our boxes in homelab or customers even if they had faulty hardware in other places.

    which is somehow curious since the first Fritz!Box the technician installed was also faulty

    Hmm perhaps power or cabling issues that knocks them out? Perhaps some short circuit problem via bad coaxes or power lines?

    The UnityMedia cable internet was only bought to temporarily have faster internet - we will get fibre internet in half a year or something. I am not sure how my experience relates to other customers but this is just.

    Definetly on the lower end ;) Can't say I know a case that fits your problem description and as I'm working and living in an area that also has UM as ISP (one of the three states they cover in germany) we never had quite that problems. Of course much of their support depends on third party contractors doing HW service on site which can be top or flop.

    PS: I did the Telekom DSL configuration of pfSense from scratch again and saw that the WAN rule is indeed not needed. I only had an additional OpenVPN rule.

    Yeah, that's how it should run :) That's also why we are very curious, why the other box won't work that way...

    Also as that whole case sounds like a "company" issue (or do you get fibre to the home?), if it stays a problem, you can think about the 2nd line of my sig ;)



  • @JeGr said in (SOLVED) Problem with client connect through static IP cable internet:

    @paprikawuerzung said in (SOLVED) Problem with client connect through static IP cable internet:

    It switches from 100Mbit on the LAN port (it should be 1000Mbit but this somehow does not work at all) to 10Mbit.

    Urgh, that sounds a lot like bad hardware. Never saw that behavior on our boxes in homelab or customers even if they had faulty hardware in other places.

    which is somehow curious since the first Fritz!Box the technician installed was also faulty

    Hmm perhaps power or cabling issues that knocks them out? Perhaps some short circuit problem via bad coaxes or power lines?

    The UnityMedia cable internet was only bought to temporarily have faster internet - we will get fibre internet in half a year or something. I am not sure how my experience relates to other customers but this is just.

    Definetly on the lower end ;) Can't say I know a case that fits your problem description and as I'm working and living in an area that also has UM as ISP (one of the three states they cover in germany) we never had quite that problems. Of course much of their support depends on third party contractors doing HW service on site which can be top or flop.

    PS: I did the Telekom DSL configuration of pfSense from scratch again and saw that the WAN rule is indeed not needed. I only had an additional OpenVPN rule.

    Yeah, that's how it should run :) That's also why we are very curious, why the other box won't work that way...

    Also as that whole case sounds like a "company" issue (or do you get fibre to the home?), if it stays a problem, you can think about the 2nd line of my sig ;)

    So, the internet seems to be working. I installed OPNSense instead of pfSense and used another machine for the firewall.
    With OPNSense, everything is working as intended and without any configuration hassle at all. True plug and play, no additional WAN rule, ... The initial reason I looked into OPNSense was that pfSense could not even be installed on the new machine - there were some cryptic "unregistered use of fpu in kernel" error on bootup - before even starting to install... I believe you if you say my experience is on the lower end.

    To all who posted here: thanks a lot for your help! ๐Ÿ˜„



  • It's working now that you've changed everything? I'm wondering if the hardware was the problem all along.



  • @KOM Yeah, its working just fine without hassle. Would be very strange if the hardware would actually block traffic instead of pfSense OR pfSense would block certain traffic because of different hardware OR ... I would have tested it on the new hardware - but as I said before: pfSense somehow is not installable on this machine (I tried a lot of different BIOS settings, ...). I still guess it's a problem of pfSense since the changes I made to the default OPNSense installation are (for all that matters) exactly the same as the ones I tried with pfSense - no special rules, nothing.



  • Both pfSense and OPNsense are based on FreeBSD, 11.1 and 11.2 respectively. It doesn't make sense that you could install OPNsense based on 11.1 but not pfSense based on 11.2 on the same hardware.

    Oh well, at least it's working for you.



  • @KOM

    @KOM said in (SOLVED) Problem with client connect through static IP cable internet:

    Both pfSense and OPNsense are based on FreeBSD, 11.1 and 11.2 respectively. It doesn't make sense that you could install OPNsense based on 11.1 but not pfSense based on 11.2 on the same hardware.

    Oh well, at least it's working for you.

    11.1 and 11.2 respectively.

    A lot of things did not make sense in this whole process ๐Ÿ˜„ Maybe it was the hardware, maybe it was pfSense. Same to me if I am honest since OPNSense with the new machine installed/worked just fine and from the functionality they seem to overlap quite heavily. Works for me.


Log in to reply