Access Modem @ 192.168.15.1
-
pfSense:
WAN @ 192.168.15.2
LAN @ 10.0.0.254Modem @ 192.168.15.1
pfSsense can ping the modem however the LAN cannot reach the modem
I need to be able to access the modem GUI to configure it.
What is blocking the LAN from accessing the modem?
-
@mcmurphy there shouldn't be anything, you would be able to access that out of the box to be honest.
Have you changed the rules on lan other than the default any any rule? Have you put in any rules in floating? Are you policy routing - ie sending traffic out say a vpn on your lan rules?
-
@johnpoz
Thanks for the reply.
I can see no rules that would be blocking this.Ahhh, I think I know why. pfSense is being setup to replace the current router so it does not have the correct GW IP address to avoid conflicts with the production router.
Sorry :)
-
@mcmurphy so your saying clients are not pointing pfsense for their gateway.. Yeah that would explain why lan can not get to pfsense wan ;)
-
J jimp moved this topic from Problems Installing or Upgrading pfSense Software on
-
Most likely a back route to the LAN Subnet is missing on the Modem.
-
@averlon Out of the box pfsense would be natting anything in the lan to the wan address. So no you don't need a route in the modem for it to answer 192.168.15.2 when its address is 192.168.15.1
If they had turned off natting, then lan clients sure wouldn't going anywhere anyway. Because like you said how would they get back.. But out of the box pfsense would be natting.
-
@johnpoz A RFC 1918 WAN address implies that the actual WAN connection is somewhere else and NAT isn't necessarily enabled for that particular interface. Since no rules can be identified, what may block the connection, a routing issue would be my best guess.
-
@averlon your overthinking it..
Out of the box pfsense will nat traffic to its wan address, doesn't matter if public or rfc1918.. If interface has a gateway set on it, its a wan to pfsense. Any lan side traffic going out this gateway will be natted to that address.
Yest the default wan rule of block rfc1918 would block unsolicited inbound traffic to the wan address. But if this was a client going to that 192.168.15.1 address the answer would be allowed by the state, that block rfc1918 rule wouldn't be evaluated because states are evaluated before rules.
-
Yes, it's possible all the outbound NAT could be happening at some upstream router but that would be a more complex setup. By default pfSense will outbound NAT on it's WAN whether or not it's in a private subnet.
Steve
-
I simply don't assume somebody would put the management interface of their modem on the actual WAN nor that everybody is running on default NAT Mode. Call it overthinking, if you like ;)
-
@averlon who says its the management network.. More likely he is just misusing the term "modem" and its actually a gateway doing nat..
Or 192.168.15.1 could be another default for modems like 192.168.100.1 which is my cable modems default IP.
None of that really matters. What he stated was pfsense IP was 15.2 and its gateway is 15.1 - in that sort of setup pfsense would nat anything behind it to the 15.2 address, and should be able to talk to the 15.1 address.
If the clients were actually using the pfsense lan IP as there gateway.
-
@johnpoz said in Access Modem @ 192.168.15.1:
who says its the management network.. More likely he is just misusing the term "modem" and its actually a gateway doing nat..
mcmurphy said in Access Modem @ 192.168.15.1:
I need to be able to access the modem GUI to configure it.
If you say it is more likely a gateway doing NAT, it supports my theory that NAT isn't necessarily enabled on the pfsense. Believe it or not, some people change default settings and don't do double NAT where it isn't needed. Actually some GW settings were change to make it work, ergo there was something off about the routing and it's most likely not the routing on the pfsense, since the 192.168.15.0/? network is a direct connected one and would work with NAT enabled as long not firewall rules interfering.
What's the point anyway? Issue is solved for 3 days now what I didn't notice when I posted my theory about a possible cause. Thank you for clarifying that NAT is enabled per default on pfsense WAN. -
@averlon said in Access Modem @ 192.168.15.1:
it supports my theory that NAT isn't necessarily enabled on the pfsens
So he would of had to on purpose go in and turn that off. Because out of the box its going to nat.. He not going to get good help if did that and didn't mention it.
-
@johnpoz If McMurphy decides to post the cause of the issue, we will know. Meanwhile there is no benefit of argue about it, since we both juggle on assumptions. So lets call it, have a nice evening.
-
@averlon assumptions always have to be made when info is missing ;) You assumed one thing, I assumed another ;)
I didn't see this as an argument or disagreement, just exchanging info on how based assumptions.
You have a great evening as well. But its only afternoon here, did you assume I was in your timezone - hehehe ;)
-
Hi all, I posted the cause previously.
The problem was simply that pfsense was not the default GW on the LAN.
GW @ 10.0.0.1
pfSense @ 10.0.0.254pfSense was set up in parallel to the existing GW so it could be configured to replace the existing GW.
As pfSense was not the default GW none of the LAN traffic was being routed there and accordingly the modem GUI could not be accessed from the LAN.
Simply adding a 2nd GW of 10.0.0.254 to the workstation, temporarily, allowed the modem GUI to be accessed.
