Hi Gene,
Sorry for the confusion regarding the state matches. My mind was
somewhere else (thinking of TCP flags) when I stated that they'll only
work with TCP. Rob is correct that the state matches are based on the
conntrack table and when connection tracking is enabled (which it will
be if you're using NAT or firewall) then your outgoing traffic should
have existing entries in the conntrack table. So, if you allow state
related and state established packets back in through the firewall then
the firewall will look into the conntrack table and accept or reject
based on the existence or nonexistence of a connection.
So, you can add a rule like:
rule 3 {
state {
established: "enable"
related: "enable"
}
action: "accept"
}
Which matches on all protocols.
If you have the need to create new connections from the outside or
untrusted areas of your network then you'll need to design rules that
specifically allow this traffic. It looks like Rob has configured this
for an incoming PPTP connection. Any other rules for any other types of
traffic would be created in the same way aside from specific source and
destination parameters.
I'll see what we can do to improve the firewall documentation and add
some examples for state matching and information on the conntrack
table. We are always working to improve the documentation and really
appreciate any suggestions.
Let me know if there is anything else specific I can answer for you. If
you just want to allow return traffic that is associated with traffic
that was initiated from inside your network then the rule above should
work for you.
Thanks again,
Robyn
Gene Cooper wrote:
> Hi Robyn, Rob and all,
>
> I too am new to Vyatta and I'm working on a quite similar issue. I've
> made previous posts and I've gotten a couple of pointers, but I still
> feel like I'm reinventing the wheel.
>
>
>> I apologize. You can use the "state" rules for other protocols. Why
>> don't you configure this and retest your firewall.
>>
>
> Robyn, can you explain a bit more? I think this is the key to my
> issues... I have a simpler setup than Rob. I have masq rules for
> NATing internal interfaces to the Internet and a state-matching firewall
> rule for TCP. My question is how do I deal with UDP, ICMP, and GRE?
> Allow all from 0/0? <joking>
>
> The iptables documentation says that iptables does not have the
> limitation of matching only TCP protocol. Why does Vyatta? And since
> it appears to be limited to matching only TCP, how do I best deal with
> these other protocols in a NAT/Internet scenario?
>
>
>>>> Only TCP packets can be matched with the state match conditions.
>>>> You'll also need to allow UDP, ICMP, and GRE (which it looks
>>>> like you have already) in separate rules.
>>>>
>
> Good info...any pointers for us?
>
>
>>> however, I cannot "design" rules for UDP,ICMP and GRE. How can I?
>>> This is for connections originating from trusted hosts, and SNATed
>>> to the outside world.
>>>
>
>
>>> So if I can match tcp connections by State.... why can't I do this
>>> for protocol ALL/ANY... the contrack modules are already providing
>>> state tracking for such protocols in order to perform NAT.
>>>
>
>
>>> but it's for much more than TCP. Is this a bug in vyatta?
>>>
>
> It appears like a hole in the program...
>
>
>>> Nevertheless, this is an astonishingly simple setup!! I can't
>>> believe that in all this time nobody has queried this.... I must be
>>> either doing something wrong, or not explaining my setup correctly.
>>> Nobody has yet commented one of my original queries... do I even
>>> need a firewall instance in this case? Can somebody help me on
>>> this.
>>>
>
> As has been explained, NAT rules are just not enough for an Internet
> access router. I would hope this application would be documented
> somewhere. It would have saved me hours...
>
> Thanks in advance to all,
>
> G
>
>
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
