Re: [Vyatta-users] Vyatta Stateful Firewall Issue
Hi Adrian,
First off, I apologize for the long delay in getting back to you but, I
think I have an answer for you. On the Vyatta router, try the following:
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
Then try running the nmap ACK scan again. The RST packet, which is what
nmap is expecting in return, should not even get sent by the host since
the ACK packet should be blocked by the firewall this time.
What was happening is that a state of "NEW" in iptables means exactly
that--any new TCP packet. It does not mean a new TCP packet with the
SYN flag set. The 'nf_conntrack_tcp_loose' option can be modified
however, to enforce a more stringent set of checks on incoming TCP
packets. With this option set to 0, the firewall will compare the
packet against the existing conntrack entries and drop it because it is
not a valid packet for establishing a new connection and it is not part
of an existing established connection.
The benefit of having this value set to 3 (the default) is that it will
try and pick up any existing connections that were terminated as a
result of a system reload or other unexpected failure. So, it assumes
that the new ACK packet was part of a previous connection that got
dropped and cleared from the conntrack table when the system went down.
If this is not a concern of yours, then I'd say setting it to 0 would
not cause any other problems.
An enhancement request has actually already been open to allow the
nf_conntrack_tcp_loose value to be modified via the CLI:
https://bugzilla.vyatta.com/show_bug.cgi?id=2122
Another option is to add a rule directly in iptables that drops any NEW
packets that don't have the SYN flag set. EX:
iptables -I FORWARD 1 -p tcp ! --syn -m state --state NEW -j DROP
This rule gets added to the beginning of the iptables FORWARD chain and
drops any new packets that don't have the SYN flag set. The problem
with this workaround is that you have to be careful when running
firewall rules in the CLI and in iptables as their order of entry is
very important and can cause problems or confusion if it gets out of
sync. You'll also have to script any rules that you add directly into
iptables and also the echo into the nf_conntrack_tcp_loose so that your
changes will still exist after a reboot.
I also opened an enhancement request to add TCP flag match criteria into
the Vyatta firewall. So, in the future, the rule above should be
configurable via the CLI:
https://bugzilla.vyatta.com/show_bug.cgi?id=2474
Thank you and let me know if this works for you.
-Robyn
Adrian F. Dimcev wrote:
> Hi Robyn,
> Currently I'm doing the tests in VMware because my physical test machine
> has only one working NIC.
> Since I'm limited testing in VMware I'm cautios with conclusions.
> But bellow is what I have observed.
> VMware Server 1.0.4 build-56528.
> The machine behind Vyatta is a Windows 2003 Server SE R2
> SP2(192.168.40.2).
> The host machine is using Windows XP SP2.
> Vyatta persistent install.
> Win2003---Vyatta---Real Net 192.168.22.0/24
> My gateway is 192.168.22.1 on which I enabled the WebGUI(http) and it's
> playing "by the rules" on its internal interface for easy port scanning.
> As I understand and my tests shown the "state" parameter enables
> stateful TCP inspection on Vyatta(without it I'm able to pass any TCP
> segments):
> -with "new enable" implicitly other states are disabled so only TCP SYN
> packets are allowed through Vyatta.
> Other segments like: RST, SYN+ACK and so on are denied(that's what I
> have seen).
> So the full three-way handshake will never be establised, since the ACK
> segment sent back by the host behind Vyatta is denied.
> -with "established enable" connections established through Vyatta are
> permitted.
> Thus: "new+established enable" a host behind Vyatta can establish TCP
> connections as specified by the firewall rules.
> The other states without being explicitly defined are implicitly
> "disabled".
>
> On Vyatta VC2.2 basic stuff, NAT plus a firewall rule allowing http
> traffic(with or without specifying a destination port number for TCP
> thus limiting, same results):
> Internal Network: 192.169.40.0/24
> External Network: 192.168.22.0/24
> NAT:
> [EMAIL PROTECTED] show service nat
> rule 1 {
> type: "masquerade"
> outbound-interface: "eth0"
> source {
> network: "192.168.40.0/24"
> }
> }
> Firewall:
> [EMAIL PROTECTED] show firewall
> name blah {
> rule 1 {
> protocol: "tcp"
> state {
> established: "enable"
> new: "enable"
> invalid: "disable"
> }
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "192.168.22.0/24"
> port-number 80
> }
> }
> }
> [EMAIL PROTECTED] show interfaces ethernet eth1
> hw_id: 00:0c:29:85:e8:86
> address 192.168.40.1 {
Re: [Vyatta-users] DHCP relay in vif interfaces (vc3)
Hi Sergio, There is a limitation in the VC3 release in that only 'ethX' values can be specified for DHCP relay interfaces. This is due to overly stringent validation checks. I just opened a new bug on this: https://bugzilla.vyatta.com/show_bug.cgi?id=2473 A temporary work-around can be implemented using the attachments just added to Bug 2473. There is the attachment id 238 that should be copied over the runtime file '/opt/vyatta/share/xorp/templates/rl_dhcp.tp' on your router. You will also need to apply the patch in attachment id 239 to the runtime script file '/opt/vyatta/sbin/dhcrelay-starter.pl' to disable another validation check. You will have to reboot the router for the validation checks removals to take effect, so make sure you're running off a disk rather than CDROM, or the changes will be lost. Hope this works for now, -- Marat - Original Message - From: "Sergio Garcia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 14, 2007 4:34 AM Subject: [Vyatta-users] DHCP relay in vif interfaces (vc3) > Hi all. > I hope you can help me with this doubt :) > I want to relay dhcp requests incoming from tree eth1 vif's to a dhcp > server but Vyatta VC3 only allows me to select "ethX" interfaces (X goes > from 0 to 23). > > Is it possible to do this? Launching dhcrelay manually is not a good > solution, but if it is the only way I will accept. > > Thanks in advance > > ___ > Vyatta-users mailing list > Vyatta-users@mailman.vyatta.com > http://mailman.vyatta.com/mailman/listinfo/vyatta-users > ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Vyatta BGP Router
-BEGIN PGP SIGNED MESSAGE- On Wed, 14 Nov 2007, Tony Raboza wrote: > 1. Has anybody deployed something like the above in a *production* > network and has been running it for some time (e.g. 6 months or more) > with no serious problem? The reason I ask this is because I just came > across this web site: We've been running Vyatta on our two border routers (rack-mount mini-ITX systems with mobile Core Duo and 2GB RAM) with BGP since June with no problems. We have three 100Mbps upstream connections providing us full routes, two into border01 and one into border02. The routers exchange routing information via iBGP and use VRRP to provide failover in the event we lose one of them. No major problems. A few months back we had rtrmgr crash on one of them, but VRRP worked as advertised and a simple reboot solved the problem. There were a few issues during the initial deployment, all of which turned out to be completely on one of our provider's side. Mark in the TAC went out of his way to help me diagnose these and get them solved. My only complaints were the lack of MD5 authentication and no easy to use equivalent to the IOS "show ip bgp " command - both of which I understand are fixed in the latest version (haven't upgraded yet). For the cost in both in dollars and watts, this solution blows away anything else I've seen or used in my nearly 15 years of doing this. It's been as solid (if not more so) than the Cisco 2828s and 6509s I used at my previous job. - -- Dave Pifke, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBRzsyYjuW2fOIQC3pAQEuIAP+IiGc+gwexVjABuGV3QfVjOlOqqzlHFty jVEPTAdkHwp7o/xIJLlXTJE1mSO4w47xdUHjW25esiwbJ0b1VAlZoAvnV+kSyquB rLpvcLdo/HusUuEEO4OORw3uFZdclUfdMELZpnueCL9CX7ehVyNew6Ti9DAgUbMK f6NS7OFk9xo= =IPD5 -END PGP SIGNATURE- ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Vyatta BGP Router
Hi We're thinking of running Vyatta as our border router for Internet connectivity. We will be using BGP to peer with two different ISPs. We plan on getting the full BGP Internet routes from those two BGP peers. The two ISPs will be connected to one box running Vyatta. We plan to do this to provide our company with redundant(failover) incoming/outgoing Internet connectivity - and possibly do load-sharing between those two connections. The box will also be doing NAT. Questions: 1. Has anybody deployed something like the above in a *production* network and has been running it for some time (e.g. 6 months or more) with no serious problem? The reason I ask this is because I just came across this web site: http://www.openmaniak.com/vyatta.php "We do not recommand to use BGP for the moment because of critical bugs with this powerful routing protocol. " And when I check the bugzilla, there are still indeed problems with BGP. So, I ask, for our requirements, will Vyatta do? I've seen the case studies at the Vyatta web site - but they are too "general" - some of them quite similar to our requirements but they are not giving enough detail. Anybody - can share their some of their experiences in using Vyatta for BGP on a *production* network? Thanks! Best Regards, Tony ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] DHCP relay in vif interfaces (vc3)
Hi all. I hope you can help me with this doubt :) I want to relay dhcp requests incoming from tree eth1 vif's to a dhcp server but Vyatta VC3 only allows me to select "ethX" interfaces (X goes from 0 to 23). Is it possible to do this? Launching dhcrelay manually is not a good solution, but if it is the only way I will accept. Thanks in advance ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
