Hello, @MrXermon!
We can't reproduce this bug. Maybe, there are some other errors, which can affect route-maps?
If you have the old configuration, can you check update procedure with an update to 1.2.0-LTS and current rolling?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 7 2019
Hello, @rizkidtn!
Is any problems still exist with your configuration or we can close this issue?
Hello, @dongjunbo!
Can you check behavior with new versions? If the problem still exist show us an example of such big configuration, or at least count of objects and their types in this config.
Hello, @bjtangseng!
Can you recheck this with fresh versions? Seems that in 1.2.0-LTS and rolling everything is OK. Also, if there is no VPN logs at all (for example, VPN is not configured), you can see output like in first message and then this will be not a issue.
Hello, @TrueTechy!
As I understand, this situation can exist only if interface is in down state? Can you check this behavior with fresh VyOS version?
Jan 21 2019
OK, things is more clearly now.
If you don't have any L2-filters between eth1 interfaces of VyOS instances I could recommend you first to change configuration to something like this (based on your configuration from first message):
Router 1:
Jan 15 2019
Confirmed. If we try to change variable with multiple values, will be applied only first of them. For example:
net.ipv4.tcp_wmem = 4098 16384 1643392
Hi, @bmtauer!
To be honest, it's looks like you have used bug or some non-typical behavior in 1.1.8 as feature. Your configuration looks strange from the start, so I propose to start investigation of this from detailed description of your task, which you want to solve by this all.
If you can, please, provide information about:
- Connections at eth interfaces on both (master and backup) routers. As I understand, all interfaces is connected to the same L2 segment of network? Explain why connections was made like this - this is not obvious for us now.
- What exactly you want to reach by VRRP? Just make reserved router or this is part of more complex task?
The more we understand your task, the faster we will can help to solve this problem.
Jan 8 2019
I doubt that it will be unecrypted
It can be at 100% unencrypted. If sender accept redirects, then traffic can be routed through another router. :)
By default, more optimal will be leaving send_redirects in enabled state.
I think, that better will be preventing to commit something in vpn ipsec if send_redirects is enabled for any interface, as we can't predict at 100% from which interface will be received traffic, that need to be encrypted with IPSec.
Per-interface option can help in any case, definitely. But we need to leave at least warning to user, where will be clearly said, that with enabled send_redirects some of traffic from interface with this option can be leaked through unencrypted channels.
Can you reproduce this with some other emulator, except SecureCRT and make video with this bug?
Jan 7 2019
OK. So, for now, anyone can use workarounds provided in T1011 or here. And wait for permanent fix in further builds.
Hi, @knozzle !
Provide, please, output of next command, executed in the same terminal as defected show ip bgp summary:
tput cols ; tput lines
Hi, @rizkidtn!
Policy route wouldn't work if it will be assigned to any other interface, except those from which incoming traffic will be received.
Why do you can't set policy to eth1.2400 interface? Is there some problems or errors related with this occurs?
Dec 30 2018
I can confirm, that problem with connection tracking is exist. Reason in this change in Linux kernel. Now, by default, all connection helpers is disabled. You may try to search in your log files something like:
kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead.
If you want, you may read more about this here.
So, we need to add all helpers by hand. You may try next workaround. Add this to /config/scripts/vyatta-postconfig-bootup.script:
sleep 10 iptables -t raw -I VYATTA_CT_HELPER 1 -p tcp --dport 1723 -j CT --helper pptp iptables -t raw -I VYATTA_CT_HELPER 2 -p tcp --dport 21 -j CT --helper ftp
Then reboot or, if you want tot apply it without rebooting, just execute all commands in root shell.
Dec 28 2018
I've made some tests...
I have build a lab with next configuration:
In test PC gateway to 10.2.1.0/24 is R2.
In R2 we have next routing tables:
vyos@vyos:~$ show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route
Dec 27 2018
I found. This is VPN settings.
Based on information from Linux IP stack flow diagrams, IPSec policy applying after route decision, and ICMP redirects doing before this. So we can't leave send_redirects=1 on interface, where we receive unencrypted traffic for IPSec.
But, we can:
- Check for firewall send-redirects 'enable' and prevent to commiting vpn ipsec options, when send_redirects is enabled.
- Disable send_redirects only on interfaces, where we expect incoming unencrypted IPSec traffic.
I'm not sure, what is better.
Dec 25 2018
If you just enable and reboot it works too? I've seen this problem at different routers with RC3, RC11 and rolling, but I can't find obvious reason for it.
Dec 24 2018
Dec 18 2018
Dec 17 2018
Dec 14 2018
Here what I mean.
Before enabling rp_filter:
net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.eth1.rp_filter = 0 net.ipv4.conf.eth2.rp_filter = 0 net.ipv4.conf.l2tpeth1.rp_filter = 0 net.ipv4.conf.lo.rp_filter = 0
After enabling:
net.ipv4.conf.all.rp_filter = 2 net.ipv4.conf.default.rp_filter = 2 net.ipv4.conf.eth0.rp_filter = 2 net.ipv4.conf.eth1.rp_filter = 2 net.ipv4.conf.eth2.rp_filter = 2 net.ipv4.conf.l2tpeth1.rp_filter = 2 net.ipv4.conf.lo.rp_filter = 2
After disabling:
net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 2 net.ipv4.conf.eth0.rp_filter = 2 net.ipv4.conf.eth1.rp_filter = 2 net.ipv4.conf.eth2.rp_filter = 2 net.ipv4.conf.l2tpeth1.rp_filter = 2 net.ipv4.conf.lo.rp_filter = 2
Dec 13 2018
Dec 5 2018
Dec 4 2018
Tested with 1.2.0-rolling+201812010337. Still many bugs, very hard to diagnostic it properly.
Minimal list TODO, for we can continue testing:
Checked in 1.2.0-rolling+201812010337, all works fine.
Vtysh:
root@vyos:/home/vyos# vtysh
Dec 3 2018
Nov 26 2018
Nov 20 2018
I will check fix soon.
By creating tunnels without remote side I mean something like:
ip tunnel add sit1 mode sit local 192.168.20.20 ttl 64
This is "vanilla way", as I understand.
Nov 18 2018
Nov 15 2018
Nov 11 2018
Oct 28 2018
@dmbaturin after some thinking about this problem I think that doing sg for all script is not a very good idea. There can be a situations, when we wan't to run it from other groups.
By now, I see two ways:
- add additional parameter to executable option, that will define using script vbash with template or not;
- move setting up right group to /opt/vyatta/etc/functions/script-template.
Second way seems more practical and easy for configuration migrations.
@syncer, thanks for hint. Works with:
[edit] vyos@vyos# show system task-scheduler task testtask01 { crontab-spec @reboot executable { arguments "vyattacfg /config/scripts/testscript01.script" path /usr/bin/sg } } [edit] vyos@vyos#
But this workaround is ugly a little bit (if we want to use arguments for example).
Maybe, better will be if VyOS will do this under the hood, without end-user engagement?