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 {
prefix-length: 24
}
firewall {
in {
name: "blah"
}
}
[EMAIL PROTECTED] show interfaces ethernet eth0
hw_id: 00:0c:29:85:e8:7c
address 192.168.22.55 {
prefix-length: 24
}
firewall {
}
Playing with nmap 4.20 + WinCap4.0.1 + Wireshark0.99.6a:
"Working"(get a RST segment back + Wireshark traces showing the TCP
segment passing through Vyatta):
nmap --scanflags PSHACK 192.168.22.1 -p80 -n -P0
nmap --scanflags ACK 192.168.22.1 -p80 -n -P0
nmap --scanflags URGACK 192.168.22.1 -p80 -n -P0
nmap --scanflags PSHURGACK 192.168.22.1 -p80 -n -P0
nmap -sA 192.168.22.1 -p80 -n -P0
nmap -sW 192.168.22.1 -p80 -n -P0 (the ACK story)
"Not working"(these ones don't pass through Vyatta, examples):
nmap --scanflags SYNACK 192.168.22.1 -p80 -n -P0
nmap --scanflags RSTACK 192.168.22.1 -p80 -n -P0
nmap --scanflags PSHURGFINRSTSYNACK 192.168.22.1 -p80 -n -P0
nmap --scanflags PSHURGFINRSTACK 192.168.22.1 -p80 -n -P0
nmap --scanflags PSHURGFINACK 192.168.22.1 -p80 -n -P0
nmap --scanflags PSHURGFIN 192.168.22.1 -p80 -n -P0
nmap --scanflags FINACK 192.168.22.1 -p80 -n -P0
nmap --scanflags FIN 192.168.22.1 -p80 -n -P0
nmap --scanflags RST 192.168.22.1 -p80 -n -P0
nmap --scanflags PSHFIN 192.168.22.1 -p80 -n -P0
nmap --scanflags PSHFINACK 192.168.22.1 -p80 -n -P0
nmap -sF 192.168.22.1 -p80 -n -P0
nmap -sX 192.168.22.1 -p80 -n -P0
nmap -sN 192.168.22.1 -p80 -n -P0
Interesting facts:
***nmap -sT 192.168.22.1 -p80 -n -P0
When state established disable and new enable:
->SYN
<-SYNACK
->ACK never passes through Vyatta
->RST
So 192.168.22.1 continues to send SYN+ACK since it never gets back the
expected ACK.
However all above labeled "Working" are "OK". So the "lonely" ACK for
example is able to pass but the ACK from the TCP three-way handshake is
denied.
***nmap -sA 192.168.22.1 -p80 -n -P0
When state established enable and new disabled:
This scan does not work anymore so the "lonely" ACK is denied.
Vyatta VC3 config(webgui + ssh v2 enabled):
Firewall:
[EMAIL PROTECTED] show firewall
name dog {
rule 1 {
protocol: "tcp"
state {
established: "enable"
new: "enable"
invalid: "disable"
}
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
network: "192.168.10.0/24"
}
}
rule 2 {
protocol: "udp"
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
network: "192.168.10.0/24"
}
}
rule 3 {
protocol: "icmp"
icmp {
type: "8"
code: "0"
}
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
network: "0.0.0.0/0"
}
}
rule 4 {
protocol: "icmp"
icmp {
type: "0"
code: "0"
}
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
network: "0.0.0.0/0"
}
}
rule 5 {
protocol: "tcp"
state {
established: "enable"
new: "enable"
invalid: "disable"
}
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
network: "!192.168.10.0/24"
port-number 80
port-number 443
}
}
rule 6 {
protocol: "udp"
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
network: "!192.168.10.0/24"
port-number 53
}
}
}
name ext {
rule 1 {
protocol: "udp"
action: "accept"
source {
address: "192.168.22.234"
}
destination {
port-number 500
}
}
rule 2 {
protocol: "esp"
action: "accept"
source {
address: "192.168.22.234"
}
destination {
}
}
rule 3 {
protocol: "tcp"
state {
established: "enable"
new: "enable"
invalid: "disable"
}
action: "accept"
destination {
port-number 22
}
}
}
name int {
rule 1 {
protocol: "tcp"
state {
established: "enable"
new: "enable"
invalid: "disable"
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
port-number 22
port-number 443
}
}
}
[EMAIL PROTECTED] show interfaces
loopback lo {
}
ethernet eth0 {
hw-id: 00:0c:29:3c:4c:79
address 192.168.22.225 {
prefix-length: 24
}
firewall {
local {
name: "ext"
}
}
}
ethernet eth1 {
hw-id: 00:0c:29:3c:4c:83
address 192.168.40.1 {
prefix-length: 24
}
firewall {
in {
name: "dog"
}
local {
name: "int"
}
}
}
NAT:
[EMAIL PROTECTED] show service nat
rule 1 {
type: "source"
outbound-interface: "eth0"
source {
network: "192.168.40.0/24"
}
destination {
network: "!192.168.10.0/24"
}
outside-address {
address: 192.168.22.225
}
}
A weird thing:
When I specify a firewall rule like bellow for TCP without any "state"
and with nmap send
TCP segments like the ones from "Not Working", these packets seem "to
escape" from the NAT proccess.
The outside Wireshark trace shows the source IP address(192.168.40.2)
preserved.
[EMAIL PROTECTED] show firewall
name blah {
rule 1 {
protocol: "tcp"
action: "accept"
source {
network: "192.168.40.0/24"
}
destination {
network: "192.168.22.0/24"
port-number 80
}
}
}
Since it was a long post I hope I did not type anything wrong.
Thanks,
Adrian
-------- Original Message --------
Subject: Re: [Vyatta-users] Vyatta Stateful Firewall Issue
From: Robyn Orosz <[EMAIL PROTECTED]>
Date: Wed, November 07, 2007 3:39 pm
To: "Adrian F. Dimcev" <[EMAIL PROTECTED]>
Cc: vyatta-users@mailman.vyatta.com
Hi Adrian,
What rules have you placed in your firewall and what options are you
using to send ACK segments with nmap (specific ports etc?)
Thank you,
Robyn
Adrian F. Dimcev wrote:
> I've been testing with vc2.2 too.
> Same problem regarding the ACK segment.
> Everything else seems to work just fine(is blocking other TCP segments
> with different flag combinations).
> However the "lonely" ACK segment is passing free through Vyatta.
> Looks like a bug to me.
>
>
> _______________________________________________
> 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
