DSL Modem Access
-
I have my DSL modem (actually a Viking card) connected on the WAN side of my pfSense box and I would like to be able to access its gui interface through pfSense to read its operational statistics. The modem is set to bridge mode and has a default address of 192.168.1.1 while my LAN network is in the 192.168.0 domain. My WAN interface in pfSense is doing pppoE. Is it possible to set up a firewall rule through pfSense that would allow me to access the modem by typing its IP address in a client browser window? Such a rule should not compromise my security because internet access is coming through the pppoE protocol.
???
-
Perhaps this is still applicable:
http://doc.pfsense.org/index.php/Accessing_modem_from_inside_firewall
-
Well, I finally did it–yea! My only question is why did initially creating the manual outbound NAT rule create six rules on its own before I created my own rule per the balance of the instructions (or maybe the six rules were already there)?
The instructions contained in the link provided were so damn confusing that I decided to rewrite them once I figured them out. I have actually struggled with the link instructions for hours previous to posting this thread. I present my rewrite of the instructions below for those other souls who may be tortured by the instructions contained in the link.
Accessing a DSL Modem from Inside the pfSense v. 2.0 Firewall:
Some DSL or cable modems have web interfaces on private IP addresses. Since these sit outside your firewall and do not have a public IP, accessing them is not as straight forward as it might seem. Your firewall has a public IP typically assigned to it, and sends all outbound traffic upstream to your ISP. Your ISP will not route the private subnet back to your modem, leaving it unreachable. This page describes the work around needed to access the management interface on your modem from the inside of your network. pfSense v. 2.0 actually assigns a PPPoE WAN to a virtual PPPoE adapter, not the physical port.
Note: Your modem's management IP must be on a different IP subnet than your internal network. If it is not, your attempts to connect to it will never go to the firewall to be routed out to the modem, as hosts on your internal network would try to connect to it on the local network and fail.
- Configure a New Interface:
Under Interfaces > (assign), create a new OPT interface, and assign it to the physical network card that is on WAN. For example, if your WAN on the assignment page is "PPPOE0(fxp0)", choose fxp0, and click “Save” to apply your changes.
Go to Interfaces > (your new OPT interface), and enable the interface. Select Type “Static” and under Static IP Configuration give it an alias IP address in the same subnet as your modem (for example, if your modem’s address is 192.168.1.1, use 192.168.1.2 as an "alias"). Do not set a gateway. If you like, you can rename the interface to something like “ModemAccess.” Click “Save” to apply your changes.
- Configure a Virtual IP:
You will need to add a Virtual IP for the IP alias previously assigned, so it will appear in the NAT configuration you will complete in the next step. Browse to Firewall > Virtual IPs and click +. Select the interface you created (above), select Type “Other,” and enter the alias IP you created (above) in the IP Address box. Add a title under Description and click “Save” to apply your changes.
Note: When I attempted this particular step, I received an error telling me I could not use the alias I assigned to my interface (above) when I clicked “Save” to save the Virtual IP. I got around this boggle by temporarily changing the alias of my Interface to another IP address, configuring the Virtual IP as above to the original alias, and then changing the alias of my Interface back to the original alias—do not pass go, do not collect $200.00.
- Configure an Outbound NAT Rule:
Now you need to configure NAT in order to translate traffic destined for your modem to the alias IP you created (above). This step is necessary so the modem sees the traffic sourced from an IP on its local subnet. To add the NAT rule: browse to Firewall > NAT and click the Outbound tab. Click on the Manual Outbound NAT radio button and click “Save.” pfSense automatically adds rules for LAN to WAN. If you have more than one internal subnet, ensure you add the appropriate rules for those subnets as well. Click the + to add a new Outbound NAT rule. In the Interface box, do not specify “WAN” as your interface, but instead specify the new interface you created (above). In the Source box, specify “Network,” and enter your LAN subnet (e.g., 192.168.0.0). In the Destination box, specify “Network,” and enter the subnet of your modem (e.g., 192.168.0.0). In the Translation box, select the VIP you added for the IP alias. Click “Save” to apply your changes.
You should now be able to access your modem GUI from a client computer on your LAN.
-
I'm confused, but I'm getting old and maybe Alzheimer's is setting in so please bear with me. :P I don't see what the problem is with accessing the router GUI from behind the firewall.
I'm running pfSense v. 2.0.1-RELEASE and this is my setup: router -> pfSense -> switch -> computers
My router has a private address in the 172.16.x.x range, I'm not running it in bridge mode, and my pfSense box and computers are on the 192.168.x.x network. I'm able to access the router GUI by entering it's address on the private network just the same as I did before I set up my pfSense box and haven't set up any firewall rules to facilitate it.
Everything has been working fine since I set up my pfSense box in May and I don't see what the problem is.
-
@mr_bobo
You are not running your router in bridge mode so you won't have any difficulty accessing it. This doesn't apply to you.@Nonsense
First off I'm happy you finally managed to connect to your modem gui. However what you have done is to use the technique described for 1.2.3 on a 2.0.1 install. There is no need to do this it's far more complex.Select Type “Static” and under Static IP Configuration give it an alias IP address in the same subnet as your modem (for example, if your modem’s address is 192.168.1.2, use 192.168.1.1 as an alias).
Your use of the word 'alias' here is incorrect, you are simply setting the IP address of the interface.
Note: When I attempted this particular step, I received an error telling me I could not use the alias I assigned to my interface (above) when I clicked “Save” to save the Virtual IP
Yes, you are trying to set a virtual IP with the same address as the existing IP on the interface. This is a pointless excercise, it simply duplicates the fucntionality of the actual interface. In the worse case you may get continuous 'duplicate IP' warnings in your logs.
The instructions for 2.0 at the bottom of the linked wiki page are correct.
I'm sorry if it seems like I'm being dismissive, you have obviously spent a long time trying to get this to work and hopefull you have learnt a lot along the way. :)The absolute simplest way of doing this would be as follows:
Under Interfaces > (assign), create a new OPT interface, and assign it to the physical network card that is on WAN. For example, if your WAN on the assignment page is "PPPOE0(fxp0)", choose fxp0, and Save your changes.
Go to Interfaces > (your new OPT interface), and enable the interface. Give it an IP address in the same subnet as your modem, such as 192.168.1.5/24 (For example, the same IP address suggested in for the alias in the previous instructions). Set the gateway as the IP address of your modem. Make sure this isn't the default gateway.
Done.Doing the above will allow the default setting of automatic outbound NAT to handle everything. The additional gateway will only be an issue if you have a multi-WAN setup with load balancing or failover.
Of course, 'if it aint broke don't fix it' could apply here. ;)
Steve
-
Steve:
Thanks for your comments–I always appreciate your help. You are correct that I used the word "alias" incorrectly--I did so for want of a better term. You indicate that only (my) step 1 (with your modification to gateway setup) is necessary--and I will certainly try the setup once again in the way you describe (I have not checked my logs as yet)--however, the instructions for pfSense v. 2.0 at the link above clearly state that (my) step 3 is needed, to wit:
"On 2.0, a PPPoE WAN is actually assigned to a virtual PPPoE adapter, not the physical port. So the tricks above are not needed and the NAT portion will not work at all. . . . Instead, under Interfaces > (assign), create a new OPT interface, and assign it to the physical network card that is on WAN. For example, if your WAN on the assignment page is "PPPOE0(fxp0)", choose fxp0, and Save your changes. Go to Interfaces > (your new OPT interface), and enable the interface. Give it an IP address in the same subnet as your modem, such as 192.168.1.5/24 (For example, the same IP address suggested in for the alias in the previous instructions). Do not set a gateway. If you like, you can rename the interface to something like ModemAccess. Add an Outbound NAT rule as described above but do NOT choose the WAN interface, choose your new OPT interface. [emphasis added] You should then be able to access the modem from LAN."
I added (my) step 2 because the interface I created in (my) step 1 would not appear in the available selections for the interface required in (my) step 3 (I think it was in step 3–I do not have access to my pfSense box right now) until I did so. This, I judged, to be one of the reasons why I could not get access to the modem card when I repeatedly attempted the instructions in the link several months ago. Then again, I do not claim to pretend to understand how this setup works at the present time.
The instructions you have given me (above) also differ from the instructions supplied in the link (above), as well as (my) step 1 instructions, in that the link instructions say not to set a gateway while your instructions say to set the gateway to the new interface previously created. You may recall that when I tried in this way to set the gateway to my newly-created interface way back when I attempted to get my modem card access working several months ago (see my earlier thread "Revised New Build"), the gateway would not 'take' and the setup hung up with a little circle spinning around near my gateway selection.
Please let me know your further thoughts on this matter in light of what I have written above–we may end up saving the next poor soul who attempts these instructions a lot of grief.
Thanks.
-
Hmm, OK so you had to add a virtual IP in order to able to select it in your manual outbound NAT rule. I don't know why that happened. :-\
In order to get access to the modem you need pfSense to NAT between the modem interface and the LAN interface. With NAT set to 'Automatic outbound NAT rule generation' it will only generate rules to interfaces that have a gateway assigned. Thus if you add a gateway to the modem interface pfSense will NAT to it and you can access the modem. Alternatively you can set NAT to 'Manual Outbound NAT rule generation' and add the NAT rule to the modem interface yourself.
There are pros and cons to each IMHO. I try not to set NAT to manual because leaving it as auto means I never have to remember to alter the rules when I add or remove interfaces which can cause confusion.
Adding a gateway can cause problems because the only traffic that should use it is to the modem. If for some reason it ends up being the default gateway all traffic to the internet will stop working! Problem.I was lucky with my own modem in that I could use the third meathod I detailed in the other thread where I could leave NAT set to auto and not add a gateway.
Steve
-
Steve:
By the way, in my current setup, I access my modem card gui by typing "192.168.1.1" in one of my pfSense's client's browsers.
I can save my current configuration so I may be able to restore it if necessary (!), clear my recent changes (eliminating my new interface, eliminating my Virtual IP, and eliminating my NAT rule and setting NAT back to "automatic") and then try your most recent suggestion (essentially my step 1 with an added gateway–if it will 'take').
Please keep my setup in mind (which I don't want to change):
--my DSL modem card is in bridge mode and I am running pppoE via pfSense
--my DSL modem card address is 192.168.1.1
--my pfSense router (gateway) address is 192.168.0.250
--my clients (computers, printers, WAP, etc.) use addresses in the range of 192.168.0.1-200So, per your current suggested instructions, I would do the following after I have cleared my recent changes (correct me if I am wrong):
Under Interfaces > (assign), create a new OPT interface, and assign it to the physical modem network card that is on my WAN (for example, if my WAN on the assignment page is "PPPOE0(fxp0)", I would choose fxp0), and click “Save” to apply my changes. Go to Interfaces > (my new OPT interface), and enable the interface. Select Type “Static” and under Static IP Configuration give it an IP address in the same subnet as my modem (say 192.168.1.2). I would then set the gateway to (my modem's address) 192.168.1.1 (which is not the address of my "default" pfSense router gateway). Click “Save” to apply my changes. I will create no NAT rule but leave NAT set to "automatic." Done.
I should then be able to access my modem card gui by typing 192.168.1.1 in a client browser?
-
I was lucky with my own modem in that I could use the third meathod I detailed in the other thread where I could leave NAT set to auto and not add a gateway.
Well, I'd like to take the chance to thank you, Steve, for this third method. I've just recently read about it and immediately tried it with my Draytek Vigor. It works perfectly :). I like it in particlular because I once felt and still feel uncomfortable with manual outbound NAT rule generation.
Peter
-
So, in other words, if I was able to change the subnet of my bridge modem with IP address 192.168.1.1 to 255.255.0.0 then I would be able to access its gui by entering 192.168.1.1 in any of my pfSense router client's browsers without having to make any changes to my pfSense router configuration from its default settings (this is actually option 4 from my Revised New Build thread)?
I am not sure/don't remember if my modem card offers such an option for change its subnet, but now that I actually have access to its gui, I can check.
-
Maybe.
Of the two devices I have here it works on one but not the other.Steve
-
So, in other words, if I was able to change the subnet of my bridge modem with IP address 192.168.1.1 to 255.255.0.0 then I would be able to access its gui by entering 192.168.1.1 in any of my pfSense router client's browsers without having to any changes to my pfSense router configuration from its default configuration (this is actually option 4 from my Revised New Build thread)?
Right, as long as your client browsers are members of a network starting with 192.168. and your firewall rules do not forbid accessing 192.168.1.1 or 192.168.1.x.
Peter
EDIT: Ups, Steve, you're replying a bit faster than me :), hope my posting is helpful anyway.
-
Steve:
Well, the plot thickens; unfortunately, my situation has gone from bad to worse. In the midst of experimenting with alternate "modem access" configurations on pfSense last night, I lost its connection with my Viking modem card. I restored two of my prior-working pfSense configurations to no avail: pfSense is not able to talk to my modem. I can no longer connect to the internet and I cannot ping my modem's IP address inside pfSense. pfSense, however, sees my modem's adapter and my modem is syncing with my ISP's DSLAM (pppoE over Ethernet over ATM–my ISP records show the ATM path as established).
I can't imagine how any changes I made to pfSense would have caused this connection problem, as I have reset and reconfigured my pfSense build several times since the connection dropped. I did make some changes to my modem's configuration, however, while I had access to it and while I still had internet access through it. I changed its password as well as its date and time settings--these changes should have had no effect on connectivity. I also changed its default IP address (I did not change the subnet)--again, this change should have had no affect on connectivity. Additionally, however, I compulsively changed its MTU setting from 1500 to 1492 (this setting is located in the same gui screen area as the IP address setting)--I have a feeling that this latter change may be the culpret causing my connectivity problem--perhaps the modem does not like this latter setting being changed when it is in bridge mode. I violated my trusted dictum in making these changes: change only one variable at a time and reboot the system between changes when you are unsure what the results might be.
Do you have any thoughts on this matter?
So I wasted another four hours on this project last night. The Viking card has been a grand time consumer: it is neither well documented nor well supported by its manufacturer--who is almost impossible to contact via e-mail--and it is no longer in production. My next step will be to do a hardware reset on the card--then I will see if I can access it in pfSense and change it back again into bridge mode via telnet. This task will be a bear, as I will have to pull my 1U rack-mounted unit out of its cabinet, open its chassis, and access the reset pins on the Viking card--the card is mounted face down on a 90 degree riser in the chassis, so I may have to pull it out to find its reset pins. If the manufacturer had had the insight to put a reset button on the back of the card, I would not have to go through this trouble. One of these days I would like to teach student engineers a course in ethics and human engineering.
So that is how I will be spending my Thanksgiving weekend.
:'(
-
Wow, you're really not having fun with that card. :(
I'm just on my way out the door but just quickly:
Since they are both on the same card I think we may be getting some confusing over the two devices that are needed to talk to the modem. The modem itself, some Connexant SoC, and the network adapter which presumably appears as re* in pfSense.You said you changed the modem IP address; from what to what and what subnet mask is it using?
Either you have managed to crash the modem some how or it is still there but on a different IP address. If it hasn't crashed you will be able to talk to it but you will have to change the IP/subnet mask of the re NIC to match it. There are only a few choices so it's probably worth trying them all before you remove and disassemble your server. Choices are: Whatever the default IP is, what you had it set to before any changes, what you changed it to. Possibly you misentered the address in which case that's more trouble!
Steve
-
Steve:
This was my original configuration:
–my Viking DSL modem card is in bridge mode and I am running pppoE via pfSense
--my Viking DSL modem card address is 192.168.1.1
--my pfSense router (gateway) address is 192.168.0.250
--my clients (computers, printers, WAP, etc.) use addresses in the range of 192.168.0.1-200I changed my Viking card address from 192.168.1.1 to 192.168.1.250 prior to the crash--I thought it would be convenient to remember it this way as my pfSense box is at 192.168.0.250 I did not change the subnet mask of the Viking card: it remains 255.255.255.0 The nework adapter in the Viking card appears o.k. as re(0) in pfSense.
I know I set the new address correctly because I accessed the card's gui several times using its new address in a client web browser well before the crash. I have tried resetting pfSense, setting up a static WAN at 192.168.1.3, and pinging the card at both its old and new addresses but neither address answers my ping request. I have not as yet physically touched the Viking card, so there is no way I could have damaged it.
Remember, I have two issues: 1) not being able to ping/telnet to the card, and 2) the card not connecting via pppoE with pfSense--these issues must be related.
I'll have to dig out my old Westel modem and hook it up so I will have internet access at home over the holiday weekend.
-
Steve:
The good news is that I was able to get my Viking modem card working again passing pppoE traffic with my pfSense router.
The bad news is that every time I try to configure pfSense to allow a client to connect to the Viking card's GUI, I lose my connection to the card and I must do a hardware reset on the card and reconfigure it back into bridge mode in order to reestablish a connection between pfSense and the card! My conclusion is that the Viking card does not like its GUI being accessed through pfSense, at least when it is configured in bridge mode.
To briefly change the subject, I discovered another peculiarity with my pfSense build while working on the GUI access problem. I, as you may remember, am running the embedded version of pfSense off of a USB thumb drive, which I have plugged into a USB jack (an actual jack, not a header) on my Supermicro motherboard. I thought it might be best, while I had my chassis open, to relocate the thumb drive containing pfSense to the back of my chassis (so I would not have to take the chassis apart if I needed to access the thumb drive for replacement/reloading). When I thus relocated the thumb drive (with the power off), however, I could not fully boot into pfSense! I know the thumb drive was initially loading the pfSense firmware into RAM because I reached the pfSense boot menu every time I attempted to reboot, but once pfSense was booting it hung up (every time I tried) with the error:
mountroot> GEOM: da0s1: geometry does not match label (16h,63s != 255h,63s).
GEOM: da0s2: geometry does not match label (16h,63s != 255h,63s).When I restored the thumb drive to its original USB jack on the motherboard, however, the system booted up without any problem. pfSense is somehow remembering what USB jack it is associated with (even after I do a pfSense system reset). I know it is possible to relocate a firmware-loaded USB thumb drive on my platform because I have two other boxes identical to my pfSense box running FreeNAS and I am able to relocate the USB thumb drives from the motherboards to the backs of the chassis on those boxes without encountering any problem.
What gives? Is there a way to reset this memory? I have checked the boot configuration in my BIOS and there appears to be no issue there.
-
If you change the USB connector you may end up switching the USB controller that the stick is connected to. This can result is it appearing in FreeBSD as da1s1 or da2s1, or whatever, when the kernel is looking to mount root from da0s1.
This is the same problem you usually have when you write out the nano image to a USB stick. By default it expects to connected to ad0 and you have to tell it to look at da0 instead. I don't know what freenas have done to alleviate that problem. :-\Steve
-
So even if I bought a new USB thumb drive and burned pfSense onto it, it would still want to be in da0s1? Is there a way around this default in burning the embedded image on the stick?
-
With a little help from thread and the link, http://doc.pfsense.org/index.php/Accessing_modem_from_inside_firewall
I have access to both of my dsl modems.I feel if that link was more detailed it would help a lot of people.
In case my setup will help anyone in the future here is mine.
MLPPP using two dsl modems. Router ip address is 192.168.1.1, MLPPP PPoE interface named WAN
Dsl modem 1 ip is 192.168.10.1
Dsl modem 2 ip is 192.168.20.1
Opt1 Lan port renamed MOD1, ip address 192.168.10.2/24, gateway address 192.168.10.1, MOD1GW
Opt2 Lan port renamed MOD2, ip address 192.168.20.2/24, gateway address 192.168.20.1, MOD2GWIt is important that there is only a single default gateway, as adding a second one usually selects that to be a default gateway. So go and unselect that default, just have the single WAN_PPPOE in my case.
No NAT changes are needed here.
-
I was able to follow the guide with one minor change to the outbound nat page. "Translation" was left as "interface" and not set to the modems IP.
Also have mlppp at one of our sites with two modems.
