- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Jun 11 2020
Here is my config commands that are having the "!" issue on the adddress, 3 separate NAT rules where I am using NAT to catch sneaky DNS bypass and redirect through my infrastructure
Just adding in here that it is also affecting ip addresses too, not just ports
I am on 1.3-rolling-202006101523
Jun 10 2020
+1 for this, it would be very useful for a lot of use cases, we wouldn't need to add everything to vyos-1x and the config syntax, but users could add "missing" services on their own. For example T2195
ipoe daemon allows us to use this possibility. We need to add CLI commands.
Proposed commands:
set service ipoe-server client-ip-pool name POOL1 subnet 100.64.0.0/24
Radius attribute Framed-Pool.
Tested on VyOS 1.3-rolling-202006101523
SSTP, L2TP and PPPoE work as expected.
As for pptp, needs to create an additional bug report
@alexandrestein Note that vyos 1.2 (crux) does not implement DHCPv6 PD.
Thanks a lot for your time and knowledge on VyOS.
I will try with 1.2.
@alexandrestein Or, a disguised solution is to directly use iptables instruction rules to manually implement temporary nptv6 conversion. But I don't know when it will work. You can try it.
PS: because vyos uses nftables to implement NAT in 1.3, but because of the function limitation of nftables version, this function cannot be realized at present.
If you want NPT, you may have to wait for the time to come when conditions are right, and the community may implement NPT at that time.
@jack9603301, you look to have way more knowledge on IPv6 routing and the VyOS capabilities than I.
Also in 1.2.5
vyos@vyos:~$ show protocols bfd peer 10.203.42.1 % Unknown command: show bfd peer 10.203.42.1 local-address 10.203.42.254 vrf default vyos@vyos:~$ vyos@vyos:~$ show protocols bfd peer 10.203.42.1 counters % Unknown command: show bfd peer 10.203.42.1 local-address 10.203.42.254 vrf default counters vyos@vyos:~$ vyos@vyos:~$ vyos@vyos:~$ show version Version: VyOS 1.2.5
hello Thomas
What exactly do you need ?
hello Fabio, could you please show me how the vti interfaces are presented under Linux so I can fix the code. I thought I had properly ported the code from Perl to Python must I must have misunderstood something.
I'm pretty sure it's my failure to correctly handle an edge case. I'll look into it today, should be simple enough.
Clearly a workaround is the fastest way to "fix" VyOS, but the backend code should be fixed, too. This is either ipaddrcheck https://github.com/vyos/ipaddrcheck or libcidr.
i'm wondering if this is the right approach.
This works as a workaround, but this needs to be added to the ipaddrcheck validator as an allowed host-address and not be done in a shell script
Proposed validator for host https://github.com/vyos/vyos-1x/blob/current/src/validators/ipv4-host
Do I need to do more to get the PR merged?
Jun 9 2020
@alexandrestein Vyos1.3 's npt is temporarily unavailable, but vyos1.3 basically supports dhcpv6-pd,. If there is no special reason, you can consider using a global address instead of ULA, to obtain the delegation prefix directly from ISP and distribute it to the client (via RA), instead of using ULA+NPT.
Sorry.
It had some kind of persistency and I had to turn it on again to have it working.
NPTv6 is available in VyOS 1.2 (crux) and currently not implemented in 1.3 (equuleus) as nftables package should be updated to 0.9.5 to make use of netmap.
@zsdc can you please have a look? CHanges to FRR show commands introduced here: https://github.com/vyos/vyos-1x/commit/6492541b
@alexandrestein To be honest, I don't understand why NPTs work in your configuration. It seems to have nothing to do with NPTs.
You are right.
I suppose the problem is related to T2546 and the the op-mode: T2546: migrate show interfaces tunnel,input,pseudo-ethernet,… github commit
In fact, according to official comments and my retrospection of nptv6 code, vyos has not generated any code for nptv6 at present.
I made this works.
In T2321#66700, @c-po wrote:@daniil that would work of course. You tested it manuslly that this works?
In this case, SSTP daemon trying to allocate RAM for ipv6 pool and router does not have enough RAM. Dynamic memory allocation is not implemented for ip-pools.
Maybe, in this case, we need to calculate before commit, and show commit fail message with reason?
Calculating:
2^64 bit = 18446744073709551616 bit or 2305843009213693952 byte
2305843009213693952 * 64 (structure size byte) = 147573952589676412928 byte or 137438953472 GB
Correct me if my calculation wrong.
Successfully able to create the vif-s 1234 per the above example without any issues on VyOS 1.3-rolling-202006070117:
This one works good too