Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

wizard: WAN over PPPOE - default Route is not set correctly #2186

Closed
JackTrapper opened this issue Feb 10, 2018 · 43 comments
Closed

wizard: WAN over PPPOE - default Route is not set correctly #2186

JackTrapper opened this issue Feb 10, 2018 · 43 comments
Labels
help wanted Contributor missing / timeout

Comments

@JackTrapper
Copy link

JackTrapper commented Feb 10, 2018 •
edited
Loading

Version

OPNsense 18.1-amd64
FreeBSD 11.1-RELEASE-p6
OpenSSL 1.0.2n 7 Dec 2017

Failure history

Background

The default route is set to go the physical WAN port, rather than the PPPoE virtual port:

image

image

  • I did disconnect the PPPoE connection, so the WAN interface was down; and then connected it again
  • I did re-save the WAN configuration; thinking (hoping) that it simply would fix itself

Steps to reproduce

Start fresh, and run the configuration wizard

Welcome to OPNSense! Starting wizard.

  • Next

General information.

  • Next

Time Server Information.

  • Timezone: America/Toronto
  • Next

Configure WAN Interface

  • Selected Type: PPPoE
  • PPPoE Username: [redacted]
  • PPPoE Password: [redacted]
  • Next

Configure LAN Interface

  • Next

Set Admin Web GUI Password

  • Admin Password: [redacted]
  • Admin Password AGAIN: [redacted]
  • Next

Reload Configuration

  • Reload

Finished initial configuration!

  • Congratulations! OPNsense is now configured.
  • Click to continue to the dashboard.

You are currently running in LiveCD mode. A reboot will reset the configuration. SSH remote login is disabled.

How are the routes

So now it is setup. Lets check the routes

System -> Routes -> Status

Proto Destination Gateway Flags Use MTU Netif Netif (name)
ipv4 Default link#2 U 5083 1500 re0
ipv4 [ISP gateway IP redacted] link#7 UH 0 1492 pppoe wan

So it's using the wrong interface as the default route. Lets try pinging.

Interfaces -> Diagnostics -> Ping

  • Host: 8.8.8.8

  • IP Protocol: IPv4

  • Source Address: Default

  • Count: 3

    PING 8.8.8.8 (8.8.8.8): 56 data bytes

 --- 8.8.8.8 ping statistics ---
 3 packets transmitted, 0 packets received, 100.0% packet loss
 ping: sendto: Host is down
 ping: sendto: Host is down
 ping: sendto: Host is down

Fails. Lets force use of the WAN (i.e. pppoe0) interface:

  • Host: 8.8.8.8

  • IP Protocol: IPv4

  • Source Address: WAN

  • Count: 3

    PING 8.8.8.8 (8.8.8.8) from [redacted]: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=51 time=24.503 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=24.306 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=28.037 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 24.306/25.615/28.037/1.714 ms

So if i force the use of the interface, the packets will go. It just doesn't realize the default route.

Disconnect and reconnect PPPoE

Lets try forcing a disconnect and reconnect of the PPPoE interface

Interfaces -> Overview -> WAN Interface (wan, pppoe0)

  • Status: up

  • PPPOE: up

  • Disconnect

  • Status: down

  • PPPoE: down

  • Connect

  • Status: up

  • PPPoE: up

And check the routes again

Proto Destination Gateway Flags Use MTU Netif Netif (name)
ipv4 Default link#2 U 10400 1500 re0
ipv4 [ISP gateway IP redacted] link#7 UH 0 1492 pppoe wan

Still the wrong route. What about pinging again

Interface -> Diagnostics -> Ping

  • Host: 8.8.8.8

  • IP Protocol: IPv4

  • Source Address: Default

  • Count: 3

    PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down

Nope, still cannot ping using the default gateway.

Disable and re-enable the WAN interface

Lets disable the interface:

Interfaces -> [WAN]

  • Enable: [x] Enable Interface
  • Uncheck
  • Enable: [ ] Enable Interface
  • Save
  • Apply changes

And re-enable it:

  • Enable: [ ] Enable Interface
  • Check
  • Enable: [x] Enable Interface
  • Save
  • Apply changes

And check the routes again:

System -> Routes -> Status

Proto Destination Gateway Flags Use MTU Netif Netif (name)
ipv4 Default link#2 U 12152 1500 re0
ipv4 [ISP gateway IP] link#7 UH 0 1492 pppoe wan

Still the wrong route. And ping still fails:

Interfaces -> Diagnostics -> Ping

  • Host: 8.8.8.8

  • IP Protocol: IPv4

  • Source Address: Default

  • Count: 3

    PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down

And again if i force the use of PPPoE interface directly, it works:

  • Host: 8.8.8.8

  • IP Protocol: IPv4

  • Source Address: WAN

  • Count: 3

    PING 8.8.8.8 (8.8.8.8) from [redacted]: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=51 time=24.503 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=24.306 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=28.037 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 24.306/25.615/28.037/1.714 ms

Even though the PPPoE interface is up, the default interface is out the physical WAN port - with traffic going nowhere.

System -> Routes -> Status

Proto Destination Gateway Flags Use MTU Netif Netif (name) Expire
ipv4 default link#2 U 81208 1500 re0
ipv4 [ISP gateway IP] link#7 UH 0 1492 pppoe0 wan

Even though my PPPoE interface is up

System -> Gateways -> Status

Name Gateway Monitor RTT Loss Status Description
WAN_PPPOE [ISP gateway IP] none 0.0 ms 0.0 % Online Interface WAN_PPPOE Gateway

If you compare that to pfSense:

Destination Gateway Flags Use Mtu Netif Expire
default [ISP gateway IP] UGS 48915 1492 pppoe0
192.168.1.0/24 link#1 U 9999049 1500 em0
[ISP gateway IP] link#7 UH 172033 1492 pppoe0
@jackBzzz
Copy link

Brilliant report!
One point, though: note what has been redacted, then search those bits in your report before submitting it :) - looking at that address in block 216.8.128.0/18.

@andrewgreenwood
Copy link

I'm having exactly the same issue after a fresh install of 18.1 (nano) with a PPPoE connection.
Replication and symptoms are the same.

@fichtner
Copy link
Member

Same on 18.1.4? If you want I can build a Nano image based on the latest code.

@fichtner fichtner added the support Community support label Mar 13, 2018
@andrewgreenwood
Copy link

andrewgreenwood commented Mar 13, 2018 •
edited
Loading

Possibly a silly question but: Where can I get 18.1.4? The downloads I'm using are labelled just 18.1.

I originally had most things working fine until I discovered port forwarding wasn't working properly, so I did all the updates that were available followed by a reboot, but the system didn't come up after that. Then I tried a fresh install (of 18.1) and encountered this problem.

EDIT: I've just installed 18.1 from ISO in a virtual machine which also exhibited the same problem. Using the console I ran "route change default" and specified my ISP's gateway, which allowed me to then update to 18.1.4. I then rebooted. The gateway seems to be correct now, so it does look like 18.1.4 fixes this.

@fichtner
Copy link
Member

We don't have images for all 18.1.x releases as time to do QA is traded for pushing weekly updates. They are, however, sporadically released o fix image-based issues. :)

I'll provide a 18.1.4 Nano in a bit. Amd64 I guess?

@andrewgreenwood
Copy link

Yes, Amd64 please. Thank you for taking the time to do this.

@fichtner
Copy link
Member

Sure, no problem. Here it is: https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-201803131410-LibreSSL-nano-amd64.img.bz2

@andrewgreenwood
Copy link

Just to update on this - I'm now on OPNsense 18.1.5 and the problem has been resolved.

It's possible to upgrade from versions affected with the problem by manually adjusting the default route via the shell. I can't remember the exact commands I used now as it was a couple of weeks ago but it was along the lines of:

route delete default
route add default [gateway address]

For the gateway address - it was either my pppoe address, or the upstream gateway I used.

With the default gateway changed, it's then possible to upgrade and then the above commands aren't needed again :)

@fichtner fichtner self-assigned this Apr 1, 2018
@fichtner fichtner added bug Production bug and removed support Community support labels Apr 1, 2018
@fichtner fichtner added this to the 18.7 milestone Apr 1, 2018
@fichtner
Copy link
Member

fichtner commented Apr 1, 2018

Looks like it was related to this fix: f4c5e21047 more or less relating to these to changes in 18.1.4 https://github.com/opnsense/changelog/blob/9f33a2a0623addbb7378e568893af032b8ffd0db/doc/18.1/18.1.4#L10-L11

We'll issue new images based on the upcoming 18.1.6 to replace the current 18.1 ones.

Please close if you feel this is solved completely. :)

Thanks,
Franco

@fichtner fichtner mentioned this issue Apr 1, 2018
Closed
@fichtner
Copy link
Member

fichtner commented Apr 4, 2018

@JackTrapper if you have time to test we'd highly appreciate it. image for 18.1.6 are 2 weeks out and we want to get this right. 👍

@JackTrapper
Copy link
Author

JackTrapper commented Apr 4, 2018 •
edited
Loading

I'd tried the 18.1.5 DVD snapshot a few days ago, but it wouldn't boot off the USB stick (because it's a DVD snapshot). I also tried the earlier linked snapshot a few weeks ago, and it also wouldn't boot.

I was simply going to wait for another round of official releases before trying again.

Is there a "vga" snapshot around anywhere?

Edit: I tried burning it to 3 different USB sticks. Rufus swears up and down that supports bootable ISO images. It could be related to the other issue with images that i debugged.

@fichtner
Copy link
Member

fichtner commented Apr 7, 2018

@JackTrapper sorry for the delay, here's a VGA based on the upcoming 18.1.6 https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-201804070632-OpenSSL-vga-amd64.img.bz2

@JackTrapper
Copy link
Author

JackTrapper commented Apr 8, 2018 •
edited
Loading

Same problem. The default route is configured to go out the physical WAN interface, rather than out the PPPoE interface:

Proto Destination Gateway Flags Use MTU Netif Netif (name)
ipv4 default link#2 U 2455696 1500 re0
ipv4 [WAN IP] link#7 UHS 0 16384 lo0
ipv4 127.0.0.1 link#3 UH 211 16384 lo0
ipv4 192.168.1.0/24 link#1 U 13915 1500 em0 lan
ipv4 192.168.1.1 link#1 UHS 0 16384 lo0
ipv4 [gateway IP] link#7 UH 92 1492 pppoe0 wan
ipv4 [ISP DNS 1] [Gateway IP] UGHS 120 1492 pppoe0 wan
ipv4 [ISP DNS 2] [Gateway IP] UGHS 28 1492 pppoe0 wan

You can compare the equivalent from pfSense:

Destination Gateway Flags Use Mtu Netif
default [Gateway IP] UGS 16599 1492 pppoe0
127.0.0.1 link#6 UH 28 16384 lo0
192.168.1.0/24 link#1 U 29989 1500 em0
192.168.1.1 link#1 UHS 0 16384 lo0
[WAN IP] link#7 UHS 0 16384 lo0
[Gateway IP] link#7 UH 1230 1492 pppoe0
[ISP DNS 1] [Gateway IP] UGHS 0 1492 pppoe0
[ISP DNS 2] [Gateway IP] UGHS 0 1492 pppoe0

I realize this is all deep inside OpenBSD, and we have no idea what the OpenBSD networking subsystem is doing, or why. But is there some log file available through the WebGUI that would help?

@fichtner
Copy link
Member

fichtner commented Apr 8, 2018 via email

@JackTrapper
Copy link
Author

Before i plug in the USB to try the LiveCD again (and lose my Internet), can you confirm exactly now to navigate to the log you're interested in? I noticed a few logs pages; but i didn't see very many. And they were spread out under various features, rather than collected in one place.

@fichtner
Copy link
Member

fichtner commented Apr 9, 2018

System: Log File. Search for "ROUTING" in the input field.

@JackTrapper
Copy link
Author

After initial setup:

23:54:20: /rc.reload_all: ROUTING: setting IPv4 default route to [Gateway IP] 
23:54:20: /rc.reload_all: ROUTING: no IPv6 default gateway set, trying wan on 'pppoe0' () 
23:54:20: /rc.reload_all: ROUTING: no IPv4 default gateway set, trying wan on 'pppoe0' ([Gateway IP]) 
23:54:20: /rc.reload_all: ROUTING: entering configure using defaults 
23:54:17: /rc.reload_all: ROUTING: skipping IPv4 default route to wan 
23:54:17: /rc.reload_all: ROUTING: skipping IPv4 default route to wan 
23:54:17: /rc.reload_all: ROUTING: no IPv6 default gateway set, trying wan on 'pppoe0' () 
23:54:17: /rc.reload_all: ROUTING: no IPv4 default gateway set, trying wan on 'pppoe0' ([Gateway IP]) 
23:54:17: /rc.reload_all: ROUTING: entering configure using 'lan' 
23:54:15: /rc.newwanip:   ROUTING: setting IPv4 default route to [Gateway IP] 
23:54:15: /rc.newwanip:   ROUTING: no IPv6 default gateway set, trying wan on 'pppoe0' () 
23:54:15: /rc.newwanip:   ROUTING: no IPv4 default gateway set, trying wan on 'pppoe0' ([Gateway IP]) 
23:54:15: /rc.newwanip:   ROUTING: entering configure using 'wan' 
23:54:14: /rc.reload_all: ROUTING: setting IPv4 default route to [Gateway IP] 
23:54:14: /rc.reload_all: ROUTING: no IPv6 default gateway set, trying wan on 'pppoe0' () 
23:54:14: /rc.reload_all: ROUTING: no IPv4 default gateway set, trying wan on 'pppoe0' ([Gateway IP]) 
23:54:14: /rc.reload_all: ROUTING: entering configure using 'wan' 
23:52:38: /rc.bootup:     ROUTING: no IPv6 default gateway set, trying wan on 're0' () 
23:52:38: /rc.bootup:     ROUTING: no IPv4 default gateway set, trying wan on 're0' () 
23:52:38: /rc.bootup:     ROUTING: entering configure using defaults

Disconnected and Re-connecting the WAN interface:

23:57:01: /rc.newwanip:   ROUTING: setting IPv4 default route to [Gateway IP] 
23:57:01: /rc.newwanip:   ROUTING: no IPv6 default gateway set, trying wan on 'pppoe0' () 
23:57:01: /rc.newwanip:   ROUTING: no IPv4 default gateway set, trying wan on 'pppoe0' ([Gateway IP]) 
23:57:01: /rc.newwanip:   ROUTING: entering configure using 'wan'

@fichtner
Copy link
Member

It looks normal, unfortunately, always using pppoe0 except for rc.bootup, which is prior to wizard use although you probably configured re0 as WAN instead of using the automatic default re1? I'm not sure if that changes things. And speaking of the wizard, is that a general issue with PPPoE setup on your end or just the wizard misbehaving? What happens after a persistent reboot?

There needs to be a sort of baseline to when it works and when it doesn't and we don't have that except that although there are problems with PPPoE it should work better than this in any case. It looks like a transient bug and I focused on operational issues...

Before you enter the wizard, would you mind deleting the following file?

# rm /tmp/re0_defaultgw

Cheers,
Franco

@JackTrapper
Copy link
Author

you probably configured re0 as WAN instead of using the automatic default re1?

The machine has only two interfaces:

  • re0: onboard Realtek going to the modem (WAN)
  • em0: Intel Gigabit ethernet PCI card (LAN)

Usually that's how i (manually) configure them. This time i was too late pressing the keys, and it guessed right anyway. (In other words, i don't know what re1 would be, or why such a thing would come up).

And speaking of the wizard, is that a general issue with PPPoE setup on your end or just the wizard misbehaving?

As far as i know the Wizard executed properly. The PPPoE connection on the WAN adapter does connect and does function (if i force ping to use the PPPoE interface, i can ping Google, 8.8.8.8, and everyone else on the Internet).

What happens after a persistent reboot?

This is all from a Live USB stick; i can't have it over-write my router's actual hard drive - because then i lose my current pfSense. :( I never actually tried it before; but i always assume that a Live USB (like a Live CD) loses all it's configuration after reboot. Can it actually persistently run off a USB stick?

@fichtner fichtner changed the title WAN over PPPOE - default Route is not set (18.1) wizard: WAN over PPPOE - default Route is not set correctly Apr 12, 2018
@fichtner
Copy link
Member

@JackTrapper yes, you can use a nano image for that, it is read-write after boot and configuration persists

@fichtner
Copy link
Member

(you can even use the nano to install your running configuration afterwards from the console, run "opnsense-installer")

@JackTrapper
Copy link
Author

Ok, the VGA image does not persist settings between reboots; the initial setup wizard starts.

I'll try a nano image tomorrow.

@JackTrapper
Copy link
Author

Where are you finding these latest snapshots from? The earlier links are gone.

Is there a place people should be going to find them?

@fichtner
Copy link
Member

All prior snapshot images are obsolete because of https://forum.opnsense.org/index.php?topic=7987.0 or see our main mirror for direct download https://pkg.opnsense.org/releases/18.1/

@fichtner
Copy link
Member

Noticed a strange thing with the Javascript, the subnet selection was not deactivated.

# opnsense-patch 076eb9f

fichtner added a commit that referenced this issue May 25, 2018
@fichtner
wizard: add element IDs for javascript; closes #2186
0dccf5b 
(cherry picked from commit 076eb9f)
@Crisr
Copy link

Crisr commented Jun 27, 2018 •
edited
Loading

This bug is still present in the official 18.1.6 release, nano and dvd releases tested.
Starting from fresh USB image boot, set WAN and LAN interfaces manually or automatic from the command line, then using the pppoe wizard, the result is always the same: the internet doesn't work for the lan clients, but works on the router.
The routing table still displays re0 instead of pppoe0 as the default route.

@fichtner
Copy link
Member

Sure, it could be because it was fixed in 18.1.9, not 18.1.6.

@Crisr
Copy link

Crisr commented Jun 27, 2018

Ok, that's great and sorry for not realizing this.
Is there any way to download a release version, newer than 18.1.9? Sorry for asking this here, I'm only finding 18.1.6.
I know that one can build the latest version from the sources, I'm just looking for an img for a newer version.

@fichtner
Copy link
Member

We don't usually do 18.1.x image releases, but if you let me know which image/arch you are looking for I can assemble one no problem. :)

@Crisr
Copy link

Crisr commented Jun 27, 2018

If you could build an amd64 nano 18.1.9 or 18.1.10 img it would be great, thanks..

@JackTrapper
Copy link
Author

JackTrapper commented Jun 27, 2018 •
edited
Loading

The issue is still present.

  • documented it in #850: issue was closed
  • documented it in #2126; issue was closed

I tried to get an updated version; but was told they're gone.

So i was going to wait for a new version to come out so i could re-re-recreate the issue again.

@fichtner
Copy link
Member

@Crisr here you go https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-18.1.10-OpenSSL-nano-amd64.img.bz2

@JackTrapper All coding help, asking for new images or in-depth analysis is highly appreciated. The fix that went in after 18.1.6 is a likely candidate, but my hands are tied in verifying a working setup without having a PPPoE setup.

@Crisr
Copy link

Crisr commented Jun 27, 2018

Thank you fichtner!

@L1ghtn1ng
Copy link

L1ghtn1ng commented Jun 27, 2018 via email

@Crisr
Copy link

Crisr commented Jun 27, 2018 •
edited
Loading

Well, the bug is still open in 18.1.10

No way to have a working opnsense router if you have a pppoe internet config using normal installation procedures. It could probably be fixed with some command line instructions but I don't have the knowledge to understand what I'm doing at that level.
It's kind of amazing that such a showstopper bug seems to be carried over so many builds with no fix, probably there are not many using pppoe configurations to connect to the ISPs

I've tried 2 installation procedures:

  1. flashed the usb stick
  2. boot the image and then

Variant 1:
2a: set interfaces from command line (WAN on eth0, LAN on eth1)
2b: set opnsense box ip from command line
2c: access web interface and start setup wizard, setup pppoe config.
2d: access dashboard and check both lan and wan are up an running (correct IPs loaded, traceroute working).
2e: bug is open: no route to lan clients, no internet access

Variant 2:
2a: wait for the boot to finish and make sure that LAN interface and opnsense box IP is the default 192.168.1.1 in the command line after boot (eth0)
2b: access web interface and start setup wizard, setup pppoe config.
2c: access dashboard and check both lan and wan are up an running (correct IPs loaded, traceroute working).
2d: bug is open: no route to lan clients, no internet access

@fichtner fichtner reopened this Jun 27, 2018
@fichtner fichtner added the help wanted Contributor missing / timeout label Jun 27, 2018
@fichtner fichtner removed their assignment Jun 27, 2018
@fichtner
Copy link
Member

I'm clearly unable to fix this. Making room for somebody to step up.

@L1ghtn1ng image here https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-18.1.10-OpenSSL-serial-amd64.img.bz2

@L1ghtn1ng
Copy link

L1ghtn1ng commented Jun 27, 2018 via email

@Crisr
Copy link

Crisr commented Jun 28, 2018 •
edited
Loading

Update:

Well, it seems to be working after all.. don't know what caused it to begin working, however I can list what steps I took after booting for the 1st time:

  1. assigned interfaces manually from the console options in opnsense (re0 is WAN in my config, opnsense wants to put re0 to LAN by default, so I switched the interfaces with the auto-config option, took out the cables and then put them back in one by one)
  2. set router lan ip 192.168.1.1 from the opnsense console options.
  3. Reboot. So far nothing special
  4. On my LAN PC (win10) I've set the network card manually to a 192.168.1.x address to be able to reach opnsense web interface. Disabled and enabled the windows pc net interface and was able to enter the opnsense gui
  5. Took the system wizard and setup pppoe credentials and other minor settings.
  6. Checked the System: Routes: Status and the default route was set to re0 (my WAN) so the bug was still present at this stage (no internet available on the win10 pc). In the opnsense web dashboard, the pppoe connection was online and available
  7. tried to add a new route in the configuration menu, 192.168.1.0/24, wan_pppoe gateway. I didn't know what I was doing, it could be completely stupid, but I've tried it anyway, it didn't make any difference
  8. from the opnsense command line I've tried 'route add -inet 192.168.1.0/24 -link -iface pppoe0' but I've got a message that the route was already set..
  9. removed the route I've added on step 7 from the web gui.
  10. rebooted (I think, I'm not really sure about this)
  11. on the windows 10 pc in the ip4 network adapter options, reverted to DHCP settings (this was changed on step 4).
  12. enabled/disabled win10 network adapter on the win-10 pc.
    and suddenly I've got internet and routes are fixed.
    https://i.imgur.com/5tEeDiC.png

So yeah, don't know what has happened, don't know if it was something I did or did badly in the beginning, but so far it's working.
Hope this helps.

@fichtner
Copy link
Member

From what I understand this issue is about the wizard's way of setting up PPPoE which is reported to be wrong here, but this does not mean setup of PPPoE is wrong in general, which is part of why this is difficult to pin down without the actual setup and going through the trouble of inspecting what changed between wizard and manual steps.

@L1ghtn1ng
Copy link

L1ghtn1ng commented Jun 28, 2018 via email

@fichtner fichtner modified the milestones: 18.7, Future Jul 15, 2018
@fichtner fichtner removed the bug Production bug label Jul 15, 2018
@fichtner fichtner removed this from the Future milestone Jul 30, 2018
@fichtner
Copy link
Member

Has anyone tried 18.7 then?

@JackTrapper
Copy link
Author

JackTrapper commented Oct 20, 2018 •
edited
Loading

Has anyone tried 18.7 then?

I downloaded 18.7 and I tried it this morning.

Same problem. The default route is configured to go out the physical WAN interface, rather than out the PPPoE interface:

OPNSense (System -> Routes -> Status)

Proto Destination Gateway Flags Use MTU Netif Netif (name) Expire
ipv4 default link#2 U 423335 1500 re0
ipv4 [WAN IP] link#7 UHS 0 16384 lo0
ipv4 [Gateway IP] link#7 UH 279 1492 pppoe0 wan
ipv4 [DNS Server 1] [Gateway IP] UGHS 279 1492 pppoe0 wan
ipv4 [DNS Server 2] [Gateway IP] UGHS 0 1492 pppoe0 wan
ipv4 192.168.1.0/24 link#1 U 22872 1500 em0 lan
ipv4 192.168.1.1 link#1 UHS 0 16384 lo0

You can compare the equivalent from pfSense:

pfSense (Diagnosics -> Routes)

Destination Gateway Flags Use Mtu Netif Expire
default [Gateway IP] UGS 22004 1492 pppoe0
[WAN IP] link#7 UHS 0 16384 lo0
[Gateway IP] link#7 UH 363 1492 pppoe0
[DNS Server 1] [Gateway IP] UGHS 0 1492 pppoe0
[DNS Server 2] [Gateway IP] UGHS 0 1492 pppoe0
192.168.1.0/24 link#1 U 8297 1500 em0
192.168.1.1 link#1 UHS 0 16384 lo0

If you try to ping to the Internet it will fail:

But if you force the use of the PPPoE interface, it works:

I realize this is all deep inside OpenFreeBSD, and we have no idea what the OpenFreeBSD networking subsystem is doing, or why. But is there some log file available through the WebGUI that would help?

@AdSchellevis
Copy link
Member

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted Contributor missing / timeout
Milestone
No milestone
Development

No branches or pull requests
7 participants
@Crisr @fichtner @L1ghtn1ng @JackTrapper @AdSchellevis @andrewgreenwood @jackBzzz