No firmwares in 1.2.1 crux
so this not works as expected

In addition I never received any feedback from the board vendor.

@syncer The only thing I can do it monitoring upstream, which hasn't released a patch for over a year to address that issue.

Title should be something like "Add an option to exclude source IP addresses from transparent web proxying" because destination IP is a different option.

so, how can i do NAT from 10.0.0.0/8 to /24 with public ip's ?

Hello runar,
I know that it's possible to do it manually.
But I really would like to see a more integrated solution where you can add a check for the next hop inside the configuration.

Assuming this works - please reopen if not

Thanks for reopening and reporting.

• checks now for the existence of variables instead of overwriting the predefined defaults (https://github.com/vyos/vyos-1x/commit/99b2bfc74f30987d00384e384e8caa4fad28528b#diff-393bdd2f2828daf4f3a67bc8b46fcce9)

That is easy.. if level admin is set, the user is propagated into the config.. if the admin don't set it, the user is not propagated, and the user will not be able to login ..

https://vyos.readthedocs.io/en/latest/system/systemusers.html?highlight=login

I think vyos is the default, so I'll weave it into host_name.py as a default if not present in the default config.boot. Not sure why there is that difference, but on the other hand the script should and can handle missing variables.

I agree, however (https://blog.vyos.io/the-operator-level-is-proved-insecure-and-will-be-removed-in-the-next-releases) :
[...]
in the next releases that feature will be removed and operator level users will be converted to admin
[...]

Sorry, I must reopen this task. Absolutely the same situation with multiple "lower" interfaces:

OPTIONS="-6 -l ::%eth1.100-l ::%eth1.102 -u 2001:db8:0:feed::2%eth2.88 -u 2001:db8:0:feed::3%eth2.88 "
                         ^^
                         here

looking at this from a security perspective i would keep level admin, but block users of operator.. then any user is not automatically getting more privileges without the admin notice it….

When a host-name is not present, set the same default as on a newly installed device... router or vyos.. (atm. i don't remember what it says)

Looks like the option level can be removed entirely.

Migration script will be in the next rolling release (vyos-1x). Since level admin is the only level, I think it can be removed from the options tree entirely and set automatically in the config.

if host-name is not set and an IP is given to an interface script causes a an exception - maybe a default hostname could be set if the option is not in config.boot. Happens if you wipe config.boot and reboot. The default one won't have host-name configured and assigning IPs to interface still work but produce that nasty exception.

@gadams can we find your modifications somewhere?

I'm interested in using VyOS to replace a Ubiquiti USG, but I absolutely need dhcpv6-pd on ATT Fiber.

We now ship Intel ixgbe 5.5.5 driver, maybe you want to test the latest rolling?

Feel free to add patches that needs testing.
I will report back my findings with my setup (as previously PMed about)

And yea, i feel like the configuration is quite backwards in the curremt implementation... Configuration of the ppp interface should be in its own interface block, and not inside a parent interface like it is today.. the parent is only an attribute on the ppp interface...

PPP supports many forms of transfer, hense the dialer interface on cisco. almost all supported ppp/slip etc. functions are supported by the dialer function in a cisco device. Now, vyos supports PPPoE, but we don't support any other PPP "format".. if we intend to add support for more formats (serial nullmodem, modem, isdn++) then i would favor a new Dialer or Dialup interface type.. if not.. why not call it pppoe?

Cisco has the interface type Dialer which is used to configure a ton of PPPoE stuff. In addition a dialer is later assigned to a physical interface, e.g. ATM line card or an ethernet port. With this type of configuration a physical interface can be moved easily.

That option is no native rp-pppoe option, SuSE provided a patch for that feature in 2014 as far as I found out. I'm still looking for an option avoiding importing it into our repo and solve the issue with a script.

@tomjepp please test

@dmbaturin can you explain why we schedule it to the next release and not to 1.2.1 for example? Are there any policies?

I want write an follow up.

@zsdc Can you please test your use case? thx.

Working on interface-route. I think the best way is to stip that off as well, so basically interface-route has it's own script, set proto static route, route-map, table and so on too. Less likely to break when something needs top be changed, better code maintenance (at least that's what I hope for) and can be easily extended. Well, will test it out, so far there is a good performance benefit already.

VyOS 1.2.0 currently has this enabled, closing.

Confirmed it's still happening in VyOS 1.2.0 LTS