[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
[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 }
... snip
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 }
... snip
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
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 }
... snip
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 }
... snip
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
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 }
... snip
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 }
... snip
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] 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] 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] 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
[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] 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] 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] 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.com/show_bug.cgi?id=2502): set firewall name
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] 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/zero /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
