ADSL PPTP over PPPoA Transparent Bridge
-
Hi guys,
just managed to install my first pfSense as described in the subject and the WAN connection is up and running - which really is great news. I was not sure where to post my question, so went for "General Questions". Please feel free to move anywhere more appropriate.A bit of background: In Austria ADSL lines generally do use PPPoA. An ISP usually provides an ADSL modem device with an integrated router using a multi-user configuration doing NAT, firewalling, etc and through DHCP handing out private IP addresses to all systems sitting behind the router. For a multi-user configuratuion the router clearly also stores the logon credentials.
This usually works o.k., but the NAT by the ISP router clearly complicates certain things and others - like port forwarding - are not really working reliably. In order to circumvent this and assign the WAN Ip address directly to a local device, certain types of routers can be changed to a so called single-user profile whereby all standard functions bar the ADSL modem device are disabled and the connection needs to be initiated by a (router) device sitting behind the modem. This is achieved by PPTP and so far seems to work very well with pfSense.
My network currently uses the following addresses:
Internal IP-range (through pfsense DHCP): 192.168.1.x
pfsense LAN address: 192.168.1.1
pfsense WAN address: a.b.c.d - this is the public static IP address assigned by my ISP
pfsense WAN local IP address for PPTP: 10.0.0.1
pfsense WAN remote IP addess for PPTP: 10.0.0.138 - this is the address of the modem deviceI can use the internet (browsing, e-mail, etc.) from any LAN device sitting behind pfsense and also ping responsive servers on the internet as well as the pfsense device at 192.168.1.1. On the other hand I can't ping the pfsense WAN address, neither from within the LAN nor from the internet. I'm however not too much worried about that as I currently assume that this is turned off for good reasons - or am I wrong here?
My real problem now simply is that I can neither ping/access the modem at address 10.0.0.138 nor ping the pfsense WAN local address 10.0.0.1 from any device in the LAN. Pinging these interfaces however works directly from the pfsense shell (console or through ssh). Being able to access 10.0.0.138 through a web-browser is however required to be able to get to the configuration interface for my modem.
I am now stuck on how I could enable this functionality for my PCs within the LAN and would appreciate any help.
Being a rookie with pfsense, please take it easy …
Thanks in advance and regards,
Atom2
-
I currently assume that this is turned off for good reasons - or am I wrong here?
pfSense blocks everything by default, but generously adds an anti-lockout rule on LAN so you can access the pfSense webGUI from LAN and a pass-all rule on LAN to allow anything on LAN to get out to the internet.
So anything initiated to the WAN IP (ping or…) is blocked.I expect the trouble getting to 10.0.0.138 will be that 10.0.0.138 has no way to know how to route back to your on LAN at 192.168.1.n - am not sure what people do as the best solution for this, you could get onto the ADSL device by plugging in your client directly and add a route to 192.168.1.0/24 through 10.0.0.1, or use manual outbound NAT to NAT out of 10.0.0.1 to 10.0.0.138, so that 10.0.0.138 only sees that the traffic comes from 10.0.0.1 and thus can reply to it.
Others please advise the recommended solution... -
Phil - first of all many thanks for your answer.
@phil.davis:pfSense blocks everything by default, but generously adds an anti-lockout rule on LAN so you can access the pfSense webGUI from LAN and a pass-all rule on LAN to allow anything on LAN to get out to the internet.
So anything initiated to the WAN IP (ping or…) is blocked.That was sort of what I was expecting and prevents me from blocking this myself. Pretty clever default configuration …
I expect the trouble getting to 10.0.0.138 will be that 10.0.0.138 has no way to know how to route back to your on LAN at 192.168.1.n - am not sure what people do as the best solution for this, you could get onto the ADSL device by plugging in your client directly and add a route to 192.168.1.0/24 through 10.0.0.1
That sounded reasonable. I therefore hooked up a PC directly, connected through telnet to the modem and tried to add the route to it (which turned out to be a try and error excercise as there's not much documentation about the modem's cli other than the incorporated help facility). Through the web interface there is also no option to add to or modify the routing table. So after adding
ip rtadd dst=192.168.1.0/24 gateway=10.0.0.1 ```a new route showed up as evidenced by the command``` ip rtlist
Unfortunately that did not change anything - still no connection to 10.0.0.138 from any of my LAN PCs. The modem BTW is an Alcatel/Thomson ST585v6 with firmware version 5.3.9 if that means something to anybody.
[…] use manual outbound NAT to NAT out of 10.0.0.1 to 10.0.0.138, so that 10.0.0.138 only sees that the traffic comes from 10.0.0.1 and thus can reply to it.
That sounds like a good idea as well especially bearing in mind that ping from pfsense (obviously through the 10.0.0.1 I/f) to the modem works without any issues. Being new to pfsense however, I would not know how to achieve this and would appreciate some more input.
Thanks again and regards
Atom2 -
Looks like you're almost there but this page should apply equally to pptp:
https://doc.pfsense.org/index.php/How_can_i_access_my_PPPoE_Modem_on_WANSteve
-
Looks like you're almost there but this page should apply equally to pptp:
https://doc.pfsense.org/index.php/How_can_i_access_my_PPPoE_Modem_on_WANSteve
This works for me, I set it up the other day and I am using the same config with a speedtouch router set to pass pptp to wan of pfsense and it enables me to access the config of the speedtouch from my pfsense lan.
-
Looks like you're almost there but this page should apply equally to pptp:
https://doc.pfsense.org/index.php/How_can_i_access_my_PPPoE_Modem_on_WANSteve
This works for me, I set it up the other day and I am using the same config with a speedtouch router set to pass pptp to wan of pfsense and it enables me to access the config of the speedtouch from my pfsense lan.
Hi guys,
thanks for your answers. I have been able to give your suggestions a try with the following parameters:
I assigned 10.0.0.2 to the OPT interface described in the docs linked above; the local PPTP endpoint remained at 10.0.0.1 and the modem is still 10.0.0.138. As I use pfSense 2.1 I used the description for 2.0.Results were initially very good :), but in the end turned out to be rather mixed :-:
As long as the ADSL connection is not up (i.e. the ADSL line cable is not plugged into the modem) all connections work as expected: I can access the web management interface, I can ping the modem and I can telnet to the modem from a PC within my LAN. Pinging the modem from the pfSense firewall also works. BTW ping works for all three IP addresses (i.e. 10.0.0.1, 10.0.0.2, and 10.0.0.138), both from my LAN as well as from the pfSense firewall.As soon as the ADSL cable is plugged into the modem and therefore the internet connection goes up I can no longer ping the modem (10.0.0.138) from my LAN, also the web interface of the modem (10.0.0.138) is no longer reachable and last but not least new telnet connections from my LAN to the modem (10.0.0.138) can't be initiated any more; interestingly enough an already active telnet session to the modem (10.0.0.138) from my LAN (started before I plugged in the cable) stays up and remains fully operational until exit/autologout.
Ping to 10.0.0.1 and 10.0.0.2 from both the pfSense firewall and the LAN work, but ping to 10.0.0.138 - which before the changes actually worked from pfSense - now doesn't even work from pfSense any longer.Needless to say that access to the Internet is working as soon as the ADSL connection is up and running.
I don't know where to go from here, but I am sure there's enough knowledge out there to resolve this and get things moving …
Many thanks again,
Atom2
-
One more piece to the jigsaw:
tracert 10.0.0.138
from one of my PCs in the LAN reveals that data packages destined for my modem are actually routed upstream to my ISP:```
Routenverfolgung zu 10.0.0.138 über maximal 30 Abschnitte1 <1 ms <1 ms <1 ms pfSense.xxxxxxxxxx.xx [192.168.1.1]
2 12 ms 11 ms 12 ms xxxxxxxxx.xxxxxx.xx [k.l.m.n]
3 * ^Cwhere k.l.m.n is the ISPs endpoint of the pptp0 interface to which my public IP address is connected according to the relevant output from the ifconfig command on pfSense:
em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 9000
options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether xx:xx:xx:xx:xx:xx
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 xxxx::xxx:xxxx:xxxx:xxxx%em0 prefixlen 64 scopeid 0x1
nd6 options=1 <performnud>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
rl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=3808 <vlan_mtu,wol_ucast,wol_mcast,wol_magic>ether xx:xx:xx:xx:xx:xx
inet6 xxxx::xxx:xxxx:xxxx:xxxx%rl0 prefixlen 64 scopeid 0x2
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
inet 10.0.0.2 netmask 0x80000000 broadcast 127.255.255.255
nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
plip0: flags=8810 <pointopoint,simplex,multicast>metric 0 mtu 1500
enc0: flags=0<> metric 0 mtu 1536
pflog0: flags=100 <promisc>metric 0 mtu 33144
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 xxxx::1%lo0 prefixlen 64 scopeid 0x7
nd6 options=3 <performnud,accept_rtadv>pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
pptp0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1460
inet6 XXXX::XXX:XXXX:XXXX:XXXX%pptp0 prefixlen 64 scopeid 0x9
inet a.b.c.d --> k.l.m.n netmask 0xffffffff
nd6 options=3<performnud,accept_rtadv></performnud,accept_rtadv></up,pointopoint,running,noarp,simplex,multicast></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></promisc></pointopoint,simplex,multicast></full-duplex></performnud></vlan_mtu,wol_ucast,wol_mcast,wol_magic></up,broadcast,running,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast>traceroute 10.0.0.138
directly on pfSense doesn't reveal anything useful - just
1 * * *So to me this seems to indicate that the newly created NAT rule does not work as intended when the default route is up or the order of execution for some rules is not right - i.e. it first tries to forward everything out on the default route (which is up once the ADSL-cable is plugged in) and does not use the more specific instructions for forwarding to the NAT route specifically created for that purpose. But that's only my newbie'sh view of the world and I might be completely wrong … Thanks again and best regards, Atom2
-
O.K., based upon my findings in my last post, I got adventurous and tried out something: I moved the new NAT rule to the top position in pfSense's tab "Firewall: Outbound: NAT" and now I can again access the modem - ping works, telnet works and the web-interface is operational as well - at least from PCs in my LAN; pinging from the cli of pfSense still doesn't work (that probably asks for another rule or a rule move as I guess the pfSense cli initiates from 127.0.0.1/8 and clearly not from 192.168.1.0/24 so the moved rule would not trigger).
BTW internet access from my LAN also seems to work … so far so good :)
I am however not sure whether my changes may bring any unwanted side effects with it further down the line as my excercise of moving the new NAT rule to the top of the list is not documented in the link I was given by stephenw10. It could, however, be an oversight in the documentation or something that has chaged / is new in release 2.1 as the documentation link is for release 2.0.
I'd appreciate if someone could confirm / shed some more light on this for me ...
Thanks again and regards,
Atom2 -
The NAT rules, like the firewall rules,are evaluated on a top down basis (AFAIK) so moving your manual rule to the top of the list causes it to be catch your traffic to the modem.
This is an issue here but isn't mentioned on the PPPoE modem docs page because you seem to have both the modem and the PPtP tunnel end points in the same subnet. Thus when the pptp tunnel is established a NAT rule for that starts catching the traffic destined for the modem and sending it out of the default gateway (the pptp tunnel). At least that is my interpretation of it given that I've never dealt with a pptp WAN. ;)
Make sure your manual rule is specific enough not to catch anything that should be going via pptp and you should be fine.Steve