Re: [Vyatta-users] SOLVED: FIREWALL question: How can I "stealth" tcpports

2007-12-21 Thread Lindsay Burrell
Hi, Josh--

Hi, Josh

I think you speak for other users about the firewall documentation--we get
lots of questions about firewall and NAT, and that tells me that the
documentation needs to be strengthened, or made easier, or made richer, or
made simpler, or made more relevant.

Dave Roberts has offered me some suggestions for making this kind of
documentation easier for folks to approach. I've re-written the Quick Start
Guide for one of the upcoming releases along the lines of his suggestions,
and I'm hoping the result is something that will be more helpful.

If you don't mind, I'll keep your e-mail aside. When we feel the new guide
is ready to "try out," perhaps I'll ask you to take a sneak preview of it
and see what you think. I'd like to know whether, if you had seen this
documentation first, it would have worked for you and allowed you to get on
with doing what you wanted to do.

Please let me know if you'd be willing to take a look. :-)

(You can reply to me directly if you like.)

So thank you for bothering to give us for your comments. I'll try to use
them to make good improvements. 

--I do recognize how important the security features are (and yet how
complex), and how critical it is to present the right information, in just
the right amount, in the right form, so that folks can get done the things
they want to get done and not be faced with a forest of information they
don't need.

Lindsay


Lindsay Burrell
Technical Writer
Vyatta, Inc.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Josh vyatta
Sent: December 21, 2007 10:45 AM
To: [EMAIL PROTECTED]
Subject: [Vyatta-users] SOLVED: FIREWALL question: How can I "stealth"
tcpports

Adrian,
I must express my deepest appreciation for listing out the steps to
configure my firewall properly! You can't imagine my confusion until
now. Your advice has helped me accomplish my first main objective of
at least making the Vyatta as secure as a common SOHO router/firewall.
I realize it can do so much more, but if I can't make it do the
basics, how can I ever think of moving into the more complex config
goals I have.

I now have external SSH access properly configured, and internal-only
WebGui access. All other ports on the outside (including http and
https) are now filtered (or "stealthed" if scanned from GRC.com).

Why is none of this valuable information DOCUMENTED in the Vyatta
Manuals? (Or have I missed it somewhere)? It seems this is very
elementary and is probably a very common configuration goal for many
people.

Adrian, I have one more question to reference your last statement...

> In the same way you can set an in firewall instance for your local
> interface(obviuosly for tcp you will have to use the new parameter and
> now the source ports become destination ports). And also for the local
> instance of you local interface.
> Since "the rest" of the traffic is denied you need to carefully create
> your rules.

...is it necessary to set an INBOUND firewall on my eth1 internal port
for the traffic leaving OUTBOUND for http or DNS, for example?

Currently, I can access DNS/HTTP/HTTPS/FTP, etc from internal to
outbound. So wouldn't adding a firewall to eth1 open Pandora's box for
requiring ALL types of traffic to be identified and specifically
listed in order to be permitted outbound access once you add the first
firewall rule to that interface? I guess it would not be a terribly
bad idea to KNOW all the traffic that comes in OR GOES OUT, but
wouldn't that be an administrative nightmare?

Hope all of that makes sense.

Thanks again for all your help!
Josh

On 12/12/07, Adrian F. Dimcev <[EMAIL PROTECTED]> wrote:
> Hi Josh,
> There is no firewall by default on Vyatta.
> Your firewall rule does not prevent packets from "external" to your
> Vyatta itself.
> You can apply the firewall instance as in, out and local per interface.
> You have used in, meaning that packets entering that interface will be
> filtered by the firewall.
> But you are scanning Vyatta's external IP address meaning that packets
> are "sent to" the local instance.
> So you should define a rule like:
>
> set firewall name extlocal rule 10 action accept
> set firewall name extlocal rule 10 protocol tcp
> set firewall name extlocal rule 10 state new enable
> set firewall name extlocal rule 10 state established enable
> set firewall name extlocal rule 10 destination port-number 22
>
> set interfaces ethernet eth0 firewall local name extlocal
>
> Obviously this means that tcp port 22 will come as "open" because you
> wanted to use ssh from the "external net".
> Other traffic will be implicitly denied. So you won't be able to ping
> from Vyatta itself

Re: [Vyatta-users] Bonded T1

2007-10-28 Thread Lindsay Burrell
Hi, John:

Robert is correct. The Vyatta system supports MLPPP for bundling T1 lines.

The commands for MLPPP are described in the "MLPPP" chapter of the Command
Reference. There is a configuration scenario provided in the "MLPPP" chapter
of the Configuration Guide.

Hope you enjoy the feature.

Cheers,
Lindsay

--------
Lindsay Burrell
Technical Writer
Vyatta, Inc.
[EMAIL PROTECTED] 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert D.
Holtz - Lists
Sent: October 28, 2007 5:09 PM
To: 'John Jolet'; [EMAIL PROTECTED]
Subject: Re: [Vyatta-users] Bonded T1

Vyatta Community 3 supports MLPPP, which is, more or less, another name for
bonding.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Jolet
Sent: Sunday, October 28, 2007 4:02 PM
To: [EMAIL PROTECTED]
Subject: [Vyatta-users] Bonded T1

We are planning a vyatta deployment, but had postponed it because we 
need two t1's bonded.  We were told that feature is now out, but I don't 
see any reference to configuring it in the latest configuration guide.  
Can someone tell me exactly what version supports it, and where to find 
the documentation about that feature?
___
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

___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] Error in Vyatta_ConfigGuide_VC2.2_v01 VPN Section

2007-10-25 Thread Lindsay Burrell
Thank you, Adrian! I will fix this for the next release.

 

Lindsay

 



 

Lindsay Burrell

Technical Writer

Vyatta, Inc

[EMAIL PROTECTED]

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adrian F.
Dimcev
Sent: October 19, 2007 6:09 AM
To: vyatta-users@mailman.vyatta.com
Subject: [Vyatta-users] Error in Vyatta_ConfigGuide_VC2.2_v01 VPN Section

 

Hi guys,
In Vyatta_ConfigGuide_VC2.2_v01.pdf, page 229, Table 14-3 there is a serious
error regarding Diffie-Hellman group 5:
"5 Diffie-Hellman group 5 is a 1536-bit modular exponentiation
(MODP) group. This is a 1024-bit group with a key strength
approximately equivalent to symmetric keys of length 128 bits."
The first error can be easily spotted.
OK it should be:
"This is a 1538-bit group with a key strength approximately equivalent to
symmetric keys of length 128 bits."
But this is incorrect too because you need Diffie-Hellman Group 15 3072-bit
MODP for symmetric keys of length 128 bits.
At least acccording to NIST and RFCs.
Thanks!
Best,
Adrian

___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] OSPF Passive

2007-10-11 Thread Lindsay Burrell
Thanks, Jon! Thanks, Robyn!

I'll fix this for the next release.

Lindsay



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robyn Orosz
Sent: October 8, 2007 7:24 AM
To: Jon
Cc: vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] OSPF Passive

Hi Jon,

You are correct that the XORP user manual does correctly describe the 
current behavior.  This behavior has been reported as an issue in Vyatta 
Bugzilla:

https://bugzilla.vyatta.com/show_bug.cgi?id=1793

And in XORP Bugzilla:

http://www.xorp.org/bugzilla/show_bug.cgi?id=566

I'll forward this message to our tech writer so she can either make a 
note in our documentation or add a release note.  The behavior described 
in the Vyatta Command Reference is the expected behavior of an OSPF 
passive interface but, due to issue 1793, the network attached to the 
passive interface is always advertised as a /32.

To work around this issue, you can remove the passive interfaces from 
the OSPF configuration and instead advertise their networks in an OSPF 
export policy.

Thank you again for noticing this discrepancy in our documentation.  
I'll make sure something is noted until issue 1793 is fixed.

-Robyn

Jon wrote:
> Hi,
>
> In the Vyatta command reference, the use of ospf passive mode is described

> as: (With small typo)
>
> Optional. Determines whether OSPF sends hello messages out >ON< this  
> interface.
>
> If hello messages are not sent, neighbor relationships will not be  
> established on that interface. However, because the interface is still  
> part of the OSPF configuration, the subnet attached to this interface will

> still be included in the internal OSPF routes. This can be a useful  
> security mechanism at the edge of a network.
> Supported values are as follows:
> true: Hello messages will not be sent over this interface.
> false: Hello messages will be sent over this interface.
> The default is false.
>
> In the xorp user manual this mode is described as:
>
> passive: This takes the value true or false. The default setting is false

> it can be set to true to set the interface in loopback. The protocol is no

> longer run  on this address and the Router-LSA contains a host route for  
> this address.
>
> Tests we have done with this mode suggests that the xorp description is  
> the correct one, since the subnet on the interface set to passive is no  
> longer distributed.
>
> Can someone confirm this mode of operation?
>
> -- Jon
> ___
> 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

___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] Command reference

2007-10-05 Thread Lindsay Burrell
Hi, Jon:

You've found a defect in my docs. Thanks for noticing this and reporting it!

I'll fix it for the next release.

Lindsay

PS: I'll watch for the answer to your question with everyone else. :-)

_______

Lindsay Burrell
Technical Writer
Vyatta, Inc.
[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jon
Sent: October 5, 2007 5:06 AM
To: vyatta-users@mailman.vyatta.com
Subject: [Vyatta-users] Command reference

Hi,

In the last available command reference on the Wiki, there is no  
mentioning of "protocols static routes qualified-next-hop".

I believe this has been available for quite a while now?

I also have a question about the use of qualified-next-hop:

According to the XORP user manual, it states:

Qualified-next-hop: this speci?es an alternative nexthop router for the  
route, but with a
different metric. Typically it is used to install a backup static route

that will be used in case the
original next hop becomes unreachable.


What is the definition of "becomes unreachable"? Does this imply there is  
no route to it anymore, or does it take into account "not-reachable"  
messages?

Thanks,

Jon
___
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] How firewalls work using Vyatta OFR

2007-10-04 Thread Lindsay Burrell
Hi, Tony:

Thanks so much for the feedback on the documentation. You took a great deal
of trouble to help us improve the docs.

I agree with you that firewall is important and complex. It's an area where
the documentation can make a big difference.

Here are specific suggestions I see: 

-- You'd like more information on the interaction between NAT and firewall. 
-- You'd like to see some examples for additional scenarios. Perhaps these:
-- One where the Vyatta router is used as a border router
-- One using responder lists
-- Are there others? What scenarios are missing for you?

What else would you like to see? What were you looking for that might have
helped, but you didn't find it? 

Thanks again,
Lindsay

----------
Lindsay Burrell
Technical Writer
Vyatta, Inc.
[EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Cratz
Sent: October 4, 2007 1:00 AM
To: [EMAIL PROTECTED]
Subject: [Vyatta-users] How firewalls work using Vyatta OFR

After reading the Configuration guild as well as the Command
Reference I believe I now have a much better understanding
on how the OFR firewall(s) works as well as how NAT is affected.
I should also say so far my testing (I'm in the early phase
of testing) seem to prove what I state. I'm writing this
up no so much for myself but for future OFR users who may
need a better understanding.

Below is my attempt at trying to explain what I have gained.
There is still a major hole which I will point out.


The information on firewalls in the Configuration guild is
only fair. Work needs to be done to improve the information
and the firewall options which are offered. By cleaning up
the chapters others will have an easier time of understanding
firewalls. I admit I'm not a tech writer, I'm just an end
user who needs to understand the document.


The example I will use is where the OFR is a 'boader' router
between the Internet (WAN) and the internal LAN. I believe
once this example is understood any other use will be easy
to understand.

In the base configuration of OFR there is two interfaces
(eth0 - WAN side, and eth1 - LAN side). It should be noted
the OFR can support a total of 23 interfaces which means that
it can have a total of 23 firewalls.

Each interface his a firewall, which is broken into 3 parts.
And the packets are filtered as they transverse the interface.
The firewall 3 parts are:

In - deals with packets as they come through the interface
'IN'to the OFR.

Out - deals with packets as they go from the OFR out through
the interface to the remote machine(s) either on the WAN or
on the LAN.

Local - deals with packets which come from remote machine(s)
through the interface for a process running 'in' or 'on' the
OFR. The packets via this firewall will never pass through
the router to be routed to any other interface.

When a packet comes into the router and is routed via NAT
it will not pass thought a firewall UNTIL after the internal
IP address has been routed to the final target IP address and
as it transverse the interface via the 'out' firewall.

The last paragraph is only explained in the NAT section of
the Configuration guild.


While the Configuration guild somewhat touches on how the
firewall is used for NATS I believe this is really not
correctly fully explained.

I *believe* as the packet passes through the WAN interface
the 'In' firewall should be able to affect the packet BEFORE
any NAT routing happens and before the 'out' interface on the
'LAN' side and visa versa.

Maybe someone can clear this up so we have a better
understanding on how the 'In' interface firewall works with NAT
before it gets passed to the 'out' interface firewall.


Now lets look at what happen when we specified a port in a
NAT rule. Lets use port 80 (http) as an example.

As a packet comes into the OFR to be routed via NAT it has
an IP address which can be changed to a new IP before the
firewall. Specifying a port in NAT *does not* punch a hole
in the firewall. The *only* place where a hole can be punch
is in the firewall rule (not the NAT rule). So yes it is
possible that a packet for port 80 to be blocked at the
'out' firewall on the LAN interface even though port 80
has been define in a NAT rule and routed to a new IP.


 

Re: [Vyatta-users] What are bridge groups in Vyatta OFR and how they work?

2007-09-14 Thread Lindsay Burrell
You're right, Paco. A chapter on bridging should be added to the Configuration 
Guide.

Support agrees with you: they have identified this as a gap in the 
documentation. I'll raise the priority on this.

Thanks for your comment!

Lindsay

-------
Lindsay Burrell
Technical Writer
Vyatta, Inc.
[EMAIL PROTECTED]


- Original Message -
From: "Paco Alcantara" <[EMAIL PROTECTED]>
To: vyatta-users@mailman.vyatta.com
Sent: Friday, September 14, 2007 7:20:21 AM (GMT-0800) America/Los_Angeles
Subject: [Vyatta-users] What are bridge groups in Vyatta OFR and how they work?

___
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] DHCP static-mapping...

2007-09-10 Thread Lindsay Burrell
Paco, I'll add an example like this into the Configuration Guide.

Thanks, Justin!

Lindsay

_
Lindsay Burrell
Technical Writer
Vyatta, Inc.
[EMAIL PROTECTED]
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Fletcher
Sent: September 10, 2007 5:02 PM
To: Paco Alcantara
Cc: Vyatta Users
Subject: Re: [Vyatta-users] DHCP static-mapping...

Here's one example I just set up:

shared-network-name lab {
subnet 10.1.0.0/24 {
start 10.1.0.171 {
stop: 10.1.0.175
}
static-mapping abcd {
ip-address: 10.1.0.175
mac-address: 00:15:c5:b3:2e:65
}

Best,
Justin

On 9/10/07, Paco Alcantara <[EMAIL PROTECTED]> wrote:
>
> I have found no info about how to configure static mapping in DHCP server.
>
> Could you, please, give me an example...
>
> set service dhcp-server shared-network-name ETH1_POOL subnet 
> 192.168.1.0/24 static-mapping  mac add?>
>
> regards.
> Paco
> ___
> 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

___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users


Re: [Vyatta-users] DHCP: "not configured to listen on anyinterfaces!"

2007-09-04 Thread Lindsay Burrell
Yes, I should. That's a bug.

Thanks, Troopy. Sorry for the trouble.

Lindsay

_
Lindsay Burrell
Technical Writer
Vyatta, Inc.
[EMAIL PROTECTED]
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Troopy .
Sent: September 4, 2007 12:17 PM
To: [EMAIL PROTECTED]; Marat Nepomnyashy
Cc: vyatta-users@mailman.vyatta.com
Subject: Re: [Vyatta-users] DHCP: "not configured to listen on
anyinterfaces!"


Thanks for you quick answer.

Perhaps you should remove the exclude command from the VC 2.2 documentation.

REgards

TRoopy


-- Original Message --
From: "Marat Nepomnyashy" <[EMAIL PROTECTED]>
Date:  Tue, 4 Sep 2007 11:51:45 -0700

>
>Hi Troopy,
>
>We took the 'exclude' command out as it is not supported by the ISC 
>DHCP server that we are using.  The ISC people recommend configuring 
>multiple DHCP lease ranges around the IPs you want to exclude.
>
>As far as interfaces, the ISC DHCP server will automatically determine 
>the correct interface based on the DHCP lease subnet and the subnets 
>configured on the available system interfaces.  If you get a message 
>"not configured to listen on any interfaces" from the DHCP server, that 
>means that the DHCP server was not able to match any one of the 
>available system interfaces because none of the subnets the interfaces 
>were configured on included the DHCP lease subnet.  You should then 
>configure one of the system interfaces to include the DHCP lease subnet to
fix this error, which is what you did.
>
>A new DHCP server config file is generated by Vyatta each time a new 
>DHCP server configuration is committed from Vyatta.  The generated file 
>is '/opt/vyatta/etc/dhcpd.conf'.
>
>-- Marat
>
>
>- Original Message -
>From: "Troopy ." <[EMAIL PROTECTED]>
>To: "Marat Nepomnyashy" <[EMAIL PROTECTED]>; 
>; <[EMAIL PROTECTED]>
>Sent: Tuesday, September 04, 2007 1:08 AM
>Subject: Re: [Vyatta-users] DHCP: "not configured to listen on any 
>interfaces!"
>
>
>
>
>Hello,
>
>Concerning the message
>
>>not configured to listen on any interfaces!
>
>i configure an IP address on an interface and it's working now
>
>But i still don't see the exclude command.
>
>Thanks
>
>Troopy
>
>-- Original Message --
>From: "Troopy ." <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>Date:  Tue,  4 Sep 2007 09:52:08 +0200
>
>>
>>
>>Hello,
>>
>>I am sorry i have another question.
>>This time not a stupid one (i hope)
>>
>>I don't find the dhcp exclude command too.
>>
>>This time i am looking at the right place, i am at the dhcp subnet 
>>level and cannot  see the set exclude command. i can see everything 
>>like  domain-name,start,default-router but not exclude
>>
>>second thing when i just confiugure the dhcp shared-network-name and 
>>the subnet,i have the following thing:
>>
>>not configured to listen on any interfaces!
>>
>>Did i miss something,
>>i could try to play on the Debian and add
>>
>>DHCPDARGS=eth0
>>
>>to the dhcp.conf file but i think this is not a solution
>>
>>Thanks again
>>
>>TRoopy
>>
>>
>>
>>-- Original Message --
>>From: "Troopy ." <[EMAIL PROTECTED]>
>>Reply-To: <[EMAIL PROTECTED]>
>>Date:  Tue,  4 Sep 2007 08:33:42 +0200
>>
>>>
>>>Thanks very much
>>>
>>>We though that "set start" and "set stop" were at the same config level.
>>>
>>>THANKS again
>>>
>>>TRoopy
>>>
>>>
>>>-- Original Message --
>>>From: "Marat Nepomnyashy" <[EMAIL PROTECTED]>
>>>Date:  Mon, 3 Sep 2007 21:26:47 -0700
>>>
>>>>
>>>>Hello Troopy,
>>>>
>>>>The DHCP range stop address is specified under the DHCP range start 
>>>>address.
>>>>
>>>>Here's an example of a command to set the start and stop IPs of the 
>>>>DHCP range leased out on shared network named "dhcp1":
>>>>
>>>>'set service dhcp-server shared-network-name dhcp1 subnet 
>>>>192.168.2.0/24 start 192.168.2.100 stop 192.168.2.200'
>>>>
>>>>
>>>>If you do a 'show service dhcp-server', this is what the output

Re: [Vyatta-users] Flow Chart/ Diagram

2007-08-27 Thread Lindsay Burrell
"Snazzy"! I love it!!

Hi, Phen...

I hope I don't burst your bubble but--it's Visio. Sorry. :-) Plain vanilla
Visio.

Mind you, we do use the fabulous Vyatta icons developed by the fabulous
Vyatta marketing department. That makes ALL the difference. :-)

Contact me off-line if you like, and I can tell you more about it.

Lindsay
_________
Lindsay Burrell
Technical Writer
Vyatta, Inc.
[EMAIL PROTECTED]

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of FaPhenbach
Phenbach
Sent: August 26, 2007 11:32 AM
To: vyatta-users@mailman.vyatta.com
Subject: [Vyatta-users] Flow Chart/ Diagram

Does anyone know what they use to make those snazzy network charts in the
vyatta manuals?
I want to make a network diagram and update it as I expand the network.
If it boils down to me using something like dia I will do that but I rather
have something like the ones used in the manuals.

Thanks,

Phen
___
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