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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 8 2019
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?