Re: [Vyatta-users] Can't install in hard drive - it's working...
I just want to add that the line Starting wan interface: FATAL: Error inserting wanpipe (/lib/modules/ 2.6.20/kernel/drivers/net/wan/wanpipe.ko): no such device. Is safe to ignore. It just means no Sangoma WAN cards were detected. I was a bit alarmed the first time I saw that too. Its perfectly normal (unless you actually *do* have a Sangoma card installed...) -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Dec 16, 2007, at 8:16 PM, Maximo Barawid wrote: >It's been stated a couple of times on this list in the last two weeks >that vyatta has difficulty installing on an already partitioned disk. >Have you tried deleting all partitions using fdisk and then installing? Yes, I used fdisk to delete all partitions and formatted it too. But it didn't work. Thanks anyway. >The hard drive had a previous OS on it. If you don't have anything you want on the drive then after logging in to the system type: >dd /dev/hda count=1 >This will clear the partition table. Then: >install-system Thanks, it worked. Thanks to all your replies. Never miss a thing. Make Yahoo your homepage. ___ 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] SOLVED: FIREWALL question: How can I "stealth" tcpports
I'll throw my $.02 in here Examples of how to accomplish common configurations is very important, with graphics where possible to allow a vyatta beginner to easily select an appropriate config. I would add info on some of the tasks Vyatta doesn't do out of the box, like antivirus, webcontent inspection that kind of thing. Also I would but links in the documentation where it makes sense to basic sources on networking firewalls and other topics, so folks can help themselves learn. John Lindsay Burrell wrote: > 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. > ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] SOLVED: FIREWALL question: How can I "stealth" tcpports
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 say, google's ip addresses. > For that you need to add another rule allowing the returning echo reply > packet(unfortunetelly we cannot have state parameter for other protocols > then TCP with Vyatta VC3, there is a report on bugzilla for that, > https://bugzilla.vyatta
Re: [Vyatta-users] Vyatta Router Test Unsucessful last night
What kind of circuit is it? Do you need to clone your old MAC address? Short of that it would help to be able to see the config. Shane McKinley wrote: > I attempted the throw from Cisco to Vyatta last night, and failed. > >>From what I can see, the Vyatta configuration is comparable to the > Cisco's configuration with the exception of the subnets on the interface > being class C since Vyatta cannot create routes directed toward an > interface through the CLI. > > The problem: > > I could not ping my ISP's router (Vyatta's default route). I am pretty > sure they are running Cisco equipment. Everything on our side worked > fine (routes, etc). > > Could it be possible that they would need to clear arp cache or > something similar? I am really stumped on this one. I even set an > address on my laptop in the same subnet of the Vyatta up side, and it > talked to my laptop. > > If anyone has seen a similar senario and has any tips please let me > know, OR if you would like to see the cisco config and the Vyatta config > to take a look, I am willing to provide. > > Thanks, > > Shane McKinley > Habersham EMC > ___ > 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 Router Test Unsucessful last night
I attempted the throw from Cisco to Vyatta last night, and failed. >From what I can see, the Vyatta configuration is comparable to the Cisco's configuration with the exception of the subnets on the interface being class C since Vyatta cannot create routes directed toward an interface through the CLI. The problem: I could not ping my ISP's router (Vyatta's default route). I am pretty sure they are running Cisco equipment. Everything on our side worked fine (routes, etc). Could it be possible that they would need to clear arp cache or something similar? I am really stumped on this one. I even set an address on my laptop in the same subnet of the Vyatta up side, and it talked to my laptop. If anyone has seen a similar senario and has any tips please let me know, OR if you would like to see the cisco config and the Vyatta config to take a look, I am willing to provide. Thanks, Shane McKinley Habersham EMC ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Vyatta Router Test Unsucessful last night
I attempted the throw from Cisco to Vyatta last night, and failed. >From what I can see, the Vyatta configuration is comparable to the Cisco's configuration with the exception of the subnets on the interface being class C since Vyatta cannot create routes directed toward an interface through the CLI. The problem: I could not ping my ISP's router (Vyatta's default route). I am pretty sure they are running Cisco equipment. Everything on our side worked fine (routes, etc). Could it be possible that they would need to clear arp cache or something similar? I am really stumped on this one. I even set an address on my laptop in the same subnet of the Vyatta up side, and it talked to my laptop. If anyone has seen a similar senario and has any tips please let me know, OR if you would like to see the cisco config and the Vyatta config to take a look, I am willing to provide. Thanks, Shane McKinley Habersham EMC ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Recover Wiki Password
> This may be the wrong place to ask this, but where or how can > I recover my twiki password for the Vyatta community wiki? > > I see no place in the web interface for this purpose. Look here: http://www.vyatta.com/twiki/bin/view/Main/ChangePassword -- Dave ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Recover Wiki Password
This may be the wrong place to ask this, but where or how can I recover my twiki password for the Vyatta community wiki? I see no place in the web interface for this purpose. Thanks, Shane McKinley Habersham EMC ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] SOLVED: FIREWALL question: How can I "stealth" tcp ports
Ahh, About Vyatta's manuals, I would say they are pretty good. For example Vyatta_CommandRef_VC3_v02.pdf contains all I have said, you can take the pieces from there and complete your puzzle(your scenario). Regarding the security of those SOHO devices, you are much more secure with Vyatta. Adrian ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Some Vyatta articles
Hi, I have written some articles about Vyatta: How to Create a VPN Site-to-Site IPsec Tunnel Mode Connection Between a Vyatta OFR and an ISA 2006 Firewall(creating the site-to-site on Vyatta, setup a basic firewall on Vyatta in relation with the site-to-site VPN, adding the NAT rule stuff like this, nothing fancy) http://www.carbonwind.net/ISA/VyattaVPN/VyattaVPN.htm and Vyatta OFR supports multiple VPN Clients(either L2TP/IPsec and/or PPTP) located behind it(when NAT-ing) http://www.carbonwind.net/ISA/VyattaMultiVPNClients/MultiVPNClients.htm I added too the links for them on Vyatta's Community Documentation: http://www.vyatta.com/twiki/bin/view/Community/CommunityDocumentation Have fun! Adrian ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] SOLVED: FIREWALL question: How can I "stealth" tcp ports
Hi Josh, Guess what, all that info and much more is documented now here(Community Documentation): http://www.vyatta.com/twiki/bin/view/Community/CommunityDocumentation More exactly within the article How to Create a VPN Site-to-Site IPsec Tunnel Mode Connection Between a Vyatta OFR and an ISA 2006 Firewall(http://www.carbonwind.net/ISA/VyattaVPN/VyattaVPN.htm). Regarding your question about setting an "IN" firewall instance on your internal eth1 interface I would say yes, if you want security you should enable Vyatta to perform stateful inspection. And yes is you only allow HTTP the rest is implicitely denied(normal behaviour of a firewall). Also I would say that you should create an "IN" firewall instance on your external eth0 interface. Your "Local" firewall instance on your external eth0 interface does not stop packets entering that interface destined to your internal network(NAT also does not help here). If we play a little game with nmap and send some packets with the destination the IP address of a host behind Vyatta to the eth0 interface(simply telling the host on which we run nmap that the respective IP address is accesible through Vyatta's external IP address by adding a route), and you monitor with Wireshark that internal host you will see the packets sent by nmap reaching it. This "IN" firewall instance should allow the returning traffic. For example you need to allow HTTP traffic: set firewall name exttoint rule 10 action accept set firewall name exttoint rule 10 protocol tcp set firewall name exttoint rule 10 destination network "your internal network" set firewall name exttoint rule 10 state established enable set firewall name exttoint rule 10 state related enable set firewall name exttoint rule 10 state invalid disable set firewall name exttoint rule 10 source port-number 80 As said before by adding this rule all other traffic entering this interface will be implicitely denied. So you need to add rules for returning DNS traffic... Try not to confuse the "IN" and "Local" firewall instances. The "IN" firewall instance addresses traffic entering the interface and the "Local" firewall instance addresses traffic destined to Vyatta itself on that interface(altough this traffic is "entering" the interface, the two instance do not overlap, or at least I did not noticed that). If you want to gain more security you can setup an "OUT" firewall instance too. For example HTTP traffic is entering interface eth1 and exits on interface eth0. About the nightmare I think you want a wizard which would create all these for you automatically in background, say allowing HTTP from Internal to External. Allowing everything from Internal to External is easy but not secure. Best, Adrian ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] SOLVED: FIREWALL question: How can I "stealth" tcp ports
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 say, google's ip addresses. > For that you need to add another rule allowing the returning echo reply > packet(unfortunetelly we cannot have state parameter for other protocols > then TCP with Vyatta VC3, there is a report on bugzilla for that, > https://bugzilla.vyatta.com/show_bug.cgi?id=2502): > > set firewall name extlocal rule 20 action accept > set firewall name extlocal rule 20 protocol icmp > set firewall name extlocal rule 20 icmp type 0 > set firewall name extlocal rule 20 icmp code 0 > > Also I assume that you will want to filter packets entering Vyatta's > external interface. You can use something like: > > Say for Http/Https returning traffic: > set firewall name exttoint rule 10 action accept > set firewall name exttoint rule 10 protocol tcp > set firewall name exttoint rule 10 destination network "your internal > network" > set firewall name exttoint rule 10 state established enable > set firewall name exttoint rule 10 state related enable > set firewall name exttoint rule 10 state invalid disable > set firewall name exttoint rule 10 source port-number 80 > set firewall name exttoint rule 10 source port-number 443 > > For DNS returning traffic(unfortunetelly again we cannot have the state > parameter for other protocols then TCP with Vyatta VC3), this may vary > depending on your DNS design, if you are using DNS forwarders...: > set firewall name exttoint rule 14 action accept > set firewall name exttoint rule 14 source address "Your External DNS > Server Address" > set firewall name exttoint rule 14 protocol udp > set firewall name exttoint rule 14 destination "your internal network or > your internal DNS server address" > set firewall name exttoint rule 14 source port-number 53 > > set interfaces ethernet eth0 firewall in name exttoint > > 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 yo
Re: [Vyatta-users] Question about OSPF syslog events
Thanks Justin, that did the trick. Now we need to figure out how to raise the level so we can turn off debug and make it something more reasonable like warn for the OSPF info... Thanks again. --- Try lowering your syslog level to debug; the messages from OSPF are likely filtered. Best, Justin Fletcher On Dec 21, 2007 6:56 AM, Adair, Nick <[EMAIL PROTECTED]> wrote: > Hi All, > This is my configuration for syslog logging, right now we have > everything turned on and going to our syslog host. The problem is we > are not seeing OSPF notifications, I'm not sure what we are missing. We > looked in the manuals (what a concept) and found the section "Sending > OSPF messages to Syslog" and did what it indicated but it does not seem > to send OSPF info, we do see syslog messages when logrotated runs, ssh > logins, etc. We want to know when a neighbor changes. Any help would > be greatly appreciated. > > 1 protocols { > 2 ospf4 { > 3 router-id: 192.168.4.2 > 4 rfc1583-compatibility: false > 5 ip-router-alert: false > 6 traceoptions { > 7 flag { > 8 all { > 9 disable: false > 10 } > 11 } > 12 } > 13 area 0.0.0.0 { > 14 area-type: "normal" > 15 interface eth0 { > 16 link-type: "broadcast" > 17 address 192.168.3.4 { > 18 priority: 128 > 19 hello-interval: 10 > 20 router-dead-interval: 40 > 21 interface-cost: 1 > 22 retransmit-interval: 5 > 23 transit-delay: 1 > 24 passive: false > 25 disable: false > 26 } > 27 } > 28 interface eth1 { > 29 link-type: "broadcast" > 30 address 192.168.4.253 { > 31 priority: 128 > 32 hello-interval: 10 > 33 router-dead-interval: 40 > 34 interface-cost: 1 > 35 retransmit-interval: 5 > 36 transit-delay: 1 > 37 passive: false > 38 disable: false > 39 } > 40 } > 41 } > 42 } > 43 snmp { > 44 community pilot { > 45 client 192.168.100.104 > 46 client 192.168.100.105 > 47 authorization: "rw" > 48 } > 49 contact: "" > 50 description: "" > 51 location: "" > 52 } > 53 } > 54 policy { > 55 } > 56 interfaces { > 57 restore: false > 58 loopback lo { > 59 description: "" > 60 address 192.168.4.2 { > 61 prefix-length: 32 > 62 disable: false > 63 } > 64 } > 65 ethernet eth0 { > 66 disable: false > 67 discard: false > 68 description: "Uplink to RTR Cloud" > 69 hw-id: 00:50:56:85:72:6f > 70 duplex: "auto" > 71 speed: "auto" > 72 address 192.168.3.4 { > 73 prefix-length: 24 > 74 disable: false > 75 } > 76 } > 77 ethernet eth1 { > 78 disable: false > 79 discard: false > 80 description: "Connectivity to Access Switch" > 81 hw-id: 00:50:56:85:1e:3c > 82 duplex: "auto" > 83 speed: "auto" > 84 address 192.168.4.253 { > 85 prefix-length: 24 > 86 disable: false > 87 } > 88 } > 89 } > ... > 122 system { > 123 host-name: "vy-rtr-access" > 124 domain-name: "pilot-bmc.com" > 125 domain-search { > 126 domain "calbro.ase" > 127 } > 128 name-server 192.168.100.100 > 129 time-zone: "GMT" > 130 ntp-server "69.59.150.135" > 131 static-host-mapping { > 132 host-name "vy-rtr-access" { > 133 inet: 192.168.4.2 > 134 } > 135 } > ... > 150 syslog { > 151 host "192.168.3.110" { > 152 facility "*" { > 153 level: "info" > 154 } > 155 } > 156 } > ... > 164 } > > > Nick > > ___ > 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] Question about OSPF syslog events
Try lowering your syslog level to debug; the messages from OSPF are likely filtered. Best, Justin Fletcher On Dec 21, 2007 6:56 AM, Adair, Nick <[EMAIL PROTECTED]> wrote: > Hi All, > This is my configuration for syslog logging, right now we have > everything turned on and going to our syslog host. The problem is we > are not seeing OSPF notifications, I'm not sure what we are missing. We > looked in the manuals (what a concept) and found the section "Sending > OSPF messages to Syslog" and did what it indicated but it does not seem > to send OSPF info, we do see syslog messages when logrotated runs, ssh > logins, etc. We want to know when a neighbor changes. Any help would > be greatly appreciated. > > 1 protocols { > 2 ospf4 { > 3 router-id: 192.168.4.2 > 4 rfc1583-compatibility: false > 5 ip-router-alert: false > 6 traceoptions { > 7 flag { > 8 all { > 9 disable: false > 10 } > 11 } > 12 } > 13 area 0.0.0.0 { > 14 area-type: "normal" > 15 interface eth0 { > 16 link-type: "broadcast" > 17 address 192.168.3.4 { > 18 priority: 128 > 19 hello-interval: 10 > 20 router-dead-interval: 40 > 21 interface-cost: 1 > 22 retransmit-interval: 5 > 23 transit-delay: 1 > 24 passive: false > 25 disable: false > 26 } > 27 } > 28 interface eth1 { > 29 link-type: "broadcast" > 30 address 192.168.4.253 { > 31 priority: 128 > 32 hello-interval: 10 > 33 router-dead-interval: 40 > 34 interface-cost: 1 > 35 retransmit-interval: 5 > 36 transit-delay: 1 > 37 passive: false > 38 disable: false > 39 } > 40 } > 41 } > 42 } > 43 snmp { > 44 community pilot { > 45 client 192.168.100.104 > 46 client 192.168.100.105 > 47 authorization: "rw" > 48 } > 49 contact: "" > 50 description: "" > 51 location: "" > 52 } > 53 } > 54 policy { > 55 } > 56 interfaces { > 57 restore: false > 58 loopback lo { > 59 description: "" > 60 address 192.168.4.2 { > 61 prefix-length: 32 > 62 disable: false > 63 } > 64 } > 65 ethernet eth0 { > 66 disable: false > 67 discard: false > 68 description: "Uplink to RTR Cloud" > 69 hw-id: 00:50:56:85:72:6f > 70 duplex: "auto" > 71 speed: "auto" > 72 address 192.168.3.4 { > 73 prefix-length: 24 > 74 disable: false > 75 } > 76 } > 77 ethernet eth1 { > 78 disable: false > 79 discard: false > 80 description: "Connectivity to Access Switch" > 81 hw-id: 00:50:56:85:1e:3c > 82 duplex: "auto" > 83 speed: "auto" > 84 address 192.168.4.253 { > 85 prefix-length: 24 > 86 disable: false > 87 } > 88 } > 89 } > ... > 122 system { > 123 host-name: "vy-rtr-access" > 124 domain-name: "pilot-bmc.com" > 125 domain-search { > 126 domain "calbro.ase" > 127 } > 128 name-server 192.168.100.100 > 129 time-zone: "GMT" > 130 ntp-server "69.59.150.135" > 131 static-host-mapping { > 132 host-name "vy-rtr-access" { > 133 inet: 192.168.4.2 > 134 } > 135 } > ... > 150 syslog { > 151 host "192.168.3.110" { > 152 facility "*" { > 153 level: "info" > 154 } > 155 } > 156 } > ... > 164 } > > > Nick > > ___ > 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] Question about OSPF syslog events
Hi All, This is my configuration for syslog logging, right now we have everything turned on and going to our syslog host. The problem is we are not seeing OSPF notifications, I'm not sure what we are missing. We looked in the manuals (what a concept) and found the section "Sending OSPF messages to Syslog" and did what it indicated but it does not seem to send OSPF info, we do see syslog messages when logrotated runs, ssh logins, etc. We want to know when a neighbor changes. Any help would be greatly appreciated. 1 protocols { 2 ospf4 { 3 router-id: 192.168.4.2 4 rfc1583-compatibility: false 5 ip-router-alert: false 6 traceoptions { 7 flag { 8 all { 9 disable: false 10 } 11 } 12 } 13 area 0.0.0.0 { 14 area-type: "normal" 15 interface eth0 { 16 link-type: "broadcast" 17 address 192.168.3.4 { 18 priority: 128 19 hello-interval: 10 20 router-dead-interval: 40 21 interface-cost: 1 22 retransmit-interval: 5 23 transit-delay: 1 24 passive: false 25 disable: false 26 } 27 } 28 interface eth1 { 29 link-type: "broadcast" 30 address 192.168.4.253 { 31 priority: 128 32 hello-interval: 10 33 router-dead-interval: 40 34 interface-cost: 1 35 retransmit-interval: 5 36 transit-delay: 1 37 passive: false 38 disable: false 39 } 40 } 41 } 42 } 43 snmp { 44 community pilot { 45 client 192.168.100.104 46 client 192.168.100.105 47 authorization: "rw" 48 } 49 contact: "" 50 description: "" 51 location: "" 52 } 53 } 54 policy { 55 } 56 interfaces { 57 restore: false 58 loopback lo { 59 description: "" 60 address 192.168.4.2 { 61 prefix-length: 32 62 disable: false 63 } 64 } 65 ethernet eth0 { 66 disable: false 67 discard: false 68 description: "Uplink to RTR Cloud" 69 hw-id: 00:50:56:85:72:6f 70 duplex: "auto" 71 speed: "auto" 72 address 192.168.3.4 { 73 prefix-length: 24 74 disable: false 75 } 76 } 77 ethernet eth1 { 78 disable: false 79 discard: false 80 description: "Connectivity to Access Switch" 81 hw-id: 00:50:56:85:1e:3c 82 duplex: "auto" 83 speed: "auto" 84 address 192.168.4.253 { 85 prefix-length: 24 86 disable: false 87 } 88 } 89 } ... 122 system { 123 host-name: "vy-rtr-access" 124 domain-name: "pilot-bmc.com" 125 domain-search { 126 domain "calbro.ase" 127 } 128 name-server 192.168.100.100 129 time-zone: "GMT" 130 ntp-server "69.59.150.135" 131 static-host-mapping { 132 host-name "vy-rtr-access" { 133 inet: 192.168.4.2 134 } 135 } ... 150 syslog { 151 host "192.168.3.110" { 152 facility "*" { 153 level: "info" 154 } 155 } 156 } ... 164 } Nick ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
[Vyatta-users] Should I double nat or is there another way?
All, I currently use the vyatta router in one of my buildings as a replacement to an aging cisco 2610 and I have no problems with it. The problem is, in a smaller building (on a different subnet) management is thinking about putting in some public services (web, etc). At the main building, I have a 192.168.1.0 /24 LAN and the smaller building I have a 192.168.3.0/24. The internet comes in on the wan interface on the 192.168.1.0 LAN side router. How would I do a static nat to a machine, say 192.168.3.35, on the main building router? The 'other building' router would be doing a masqurade-- although I could change that. Here is a diagram to hopefully help illustrate. isp --> {main building} (normal nat) 192.168.1.0/24 > {other building} (masqurade)192.168.3.0/24 I want to give say 66.128.33.34 to 192.168.3.35. Thanks in advance and happy holidays. Aaron ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users