DSL Modem Access
-
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.
