Re: [Vyatta-users] Vyatta hangs when loading config
Hi Joe,
I'm not sure which version you are upgrading to but since you mentioned
xorpsh, I am assuming VC3?
If so, the issue is probably the : and on the firewall port-number
and port-name nodes. If you edit your config.boot file and remove the :
and from the port-name and port-number settings in the firewall
portion of your config, you should be able to load the config in the new
version.
See the following Bugzilla reports for more information:
https://bugzilla.vyatta.com/show_bug.cgi?id=2573
https://bugzilla.vyatta.com/show_bug.cgi?id=2637
Thank you,
Robyn
Joe Pub wrote:
Hi All,
I have recently done a live upgrade of vyatta to make sure everything
was up to date. I saved the config.boot file just in case. After the
reboot the loaded config was lost (not sure if this is by design on an
upgrade). So I am now trying to load the config file from the ofr
over tftp.
Now the first problem was this, it failed to parse the config file on
a firewall rule (which worked before the upgrade)
which was this.
rule 9 {
protocol: tcp
action: accept
log: disable
destination {
address: 192.168.10.2
port-number: 1723
}
}
it was complaining about the port number. So I removed this rule out
of the config file and tried to reaload it with this version.
protocols {
ospf4 {
router-id: 10.1.1.3
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth0 {
link-type: broadcast
address 172.20.1.253 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
interface lo {
link-type: broadcast
address 10.1.1.3 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
export: static-to-OSPF
}
static {
disable: false
route 0.0.0.0/0 {
next-hop: x.x.x.30
metric: 1
}
}
}
policy {
policy-statement static-to-OSPF {
term 1 {
from {
protocol: static
}
then {
action: accept
}
}
}
}
interfaces {
restore: false
loopback lo {
description:
address 10.1.1.3 {
prefix-length: 32
disable: false
}
}
ethernet eth1 {
disable: false
discard: false
description:
hw-id: 00:50:56:a8:29:60
duplex: auto
speed: auto
address x.x.x.29 {
prefix-length: 27
disable: false
}
address x.x.x.3 {
prefix-length: 27
disable: false
}
address x.x.x.2 {
prefix-length: 27
disable: false
}
firewall {
in {
name: DMZ_IN
}
}
}
ethernet eth0 {
disable: false
discard: false
description:
hw-id: 00:50:56:a8:34:ec
duplex: auto
speed: auto
address 172.20.1.253 {
prefix-length: 23
disable: false
}
vrrp {
vrrp-group: 100
virtual-address: 172.20.1.254
authentication: xx
advertise-interval: 1
preempt: true
priority: 1
}
}
}
service {
nat {
rule 2 {
type: source
inbound-interface: eth0
outbound-interface: eth1
protocols: all
source {
address: 172.20.0.1
}
destination {
network: 0.0.0.0/0
}
outside-address {
address: x.x.x.2
}
}
rule 3 {
type: destination
inbound-interface: eth1
outbound-interface: eth0
protocols: all
source {
network: 0.0.0.0/0
}
destination {
address: x.x.x.2
}
inside-address {
address: 172.20.0.1
}
}
rule 4 {
type:
Re: [Vyatta-users] Vyatta hangs when loading config
From what I can remember, this issue does not apply to NAT so you
shouldn't have to.
Thanks,
Robyn
Joe Pub wrote:
Hi,
Is this just for the firewall rules portion or should I do the same for NAT
too?
Thanks.
On 20/03/2008, Robyn Orosz [EMAIL PROTECTED] wrote:
Hi Joe,
I'm not sure which version you are upgrading to but since you mentioned
xorpsh, I am assuming VC3?
If so, the issue is probably the : and on the firewall port-number
and port-name nodes. If you edit your config.boot file and remove the :
and from the port-name and port-number settings in the firewall
portion of your config, you should be able to load the config in the new
version.
See the following Bugzilla reports for more information:
https://bugzilla.vyatta.com/show_bug.cgi?id=2573
https://bugzilla.vyatta.com/show_bug.cgi?id=2637
Thank you,
Robyn
Joe Pub wrote:
Hi All,
I have recently done a live upgrade of vyatta to make sure everything
was up to date. I saved the config.boot file just in case. After the
reboot the loaded config was lost (not sure if this is by design on an
upgrade). So I am now trying to load the config file from the ofr
over tftp.
Now the first problem was this, it failed to parse the config file on
a firewall rule (which worked before the upgrade)
which was this.
rule 9 {
protocol: tcp
action: accept
log: disable
destination {
address: 192.168.10.2
port-number: 1723
}
}
it was complaining about the port number. So I removed this rule out
of the config file and tried to reaload it with this version.
protocols {
ospf4 {
router-id: 10.1.1.3
rfc1583-compatibility: false
ip-router-alert: false
area 0.0.0.0 {
area-type: normal
interface eth0 {
link-type: broadcast
address 172.20.1.253 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
interface lo {
link-type: broadcast
address 10.1.1.3 {
priority: 128
hello-interval: 10
router-dead-interval: 40
interface-cost: 1
retransmit-interval: 5
transit-delay: 1
passive: false
disable: false
}
}
}
export: static-to-OSPF
}
static {
disable: false
route 0.0.0.0/0 {
next-hop: x.x.x.30
metric: 1
}
}
}
policy {
policy-statement static-to-OSPF {
term 1 {
from {
protocol: static
}
then {
action: accept
}
}
}
}
interfaces {
restore: false
loopback lo {
description:
address 10.1.1.3 {
prefix-length: 32
disable: false
}
}
ethernet eth1 {
disable: false
discard: false
description:
hw-id: 00:50:56:a8:29:60
duplex: auto
speed: auto
address x.x.x.29 {
prefix-length: 27
disable: false
}
address x.x.x.3 {
prefix-length: 27
disable: false
}
address x.x.x.2 {
prefix-length: 27
disable: false
}
firewall {
in {
name: DMZ_IN
}
}
}
ethernet eth0 {
disable: false
discard: false
description:
hw-id: 00:50:56:a8:34:ec
duplex: auto
speed: auto
address 172.20.1.253 {
prefix-length: 23
disable: false
}
vrrp {
vrrp-group: 100
virtual-address: 172.20.1.254
authentication: xx
advertise-interval: 1
preempt: true
priority: 1
}
}
}
service {
nat {
rule 2 {
type: source
inbound-interface: eth0
outbound-interface: eth1
protocols: all
source {
address: 172.20.0.1
Re: [Vyatta-users] cannot clear t3-options
Hi Chad, The t3-options parent node is a required node that has a set of default values nested beneath it. If you want to delete the actual option values you've set beneath t3-options to get back to the defaults, you can try deleting the values nodes individually: delete interface wan0 t3-options line-coding etc. etc. The node is required in order to load the correct driver options for either T1/ E1 or T3/ E3 so it needs to be there before you can successfully commit the serial interface configuration. Thank you, Robyn Chad Hurley wrote: Hi, When I try to delete my t3-options I get the following error: Commit Failed t1/e1/t3/e3-option is not specified Is there a work around for this? Thanks, Chad Hurley ___ 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] Clustering Causes Reboots
Hi Ben, You may be running into this issue: https://bugzilla.vyatta.com/show_bug.cgi?id=2770 which involves clustering over VIF interfaces. This bug has been fixed in Glendale and the fix will be available in the next release. You can workaround this issue in VC3 but, you'll have to manually edit your '/etc/ha.d/haresources' file. A pre-edited file will look like: vyatta 10.25.25.254 -primary-dev-name IP-address-resource You most likely have several ip addresses listed and separated by spaces. You'll need to edit the haresources file to look like: vyatta IPaddr2::10.25.25.254/24/eth2.5 --- IPaddr2::IP-address-resource/netmask/if-name Unfortunately, you'll have to do this for all 31 of your IP address resources. Then, you'll need to do a: /etc/init.d/heartbeat reload or /etc/init.d/heartbeat restart Also, the haresources file will get overwritten every time the system boots so, once you've edited it, you'll need to place a script in rc.local that copies the edited version of your file over to the actual haresources file and then runs a reload or a restart on /etc/init.d/heartbeat. Let me know if this works for you. Thank you, Robyn Ben Speckien wrote: It looks like Robyn may have been correct about not releasing IPs I tried increasing my deadtime but that didin't work. I tried removing the IPs that weren't being released and it only gave errors about the next IP on the list before rebooting. My cluster services consist of 31 IP addresses on one virtual interface, and then 1 address per two more vlans on eth0 and 1 address for eth1. router2 log : Feb 26 11:00:16 localhost xorp_rib: [ 2008/02/26 11:00:16 ERROR xorp_rib:5226 LIBFEACLIENT +228 /home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/libfeaclient/netlink_head.cc io_event ] NetlinkHead::io_event, error on RTM_NEWADDR Feb 26 11:00:16 localhost xorp_static_routes: [ 2008/02/26 11:00:16 ERROR xorp_static_routes:13985 LIBFEACLIENT +228 /home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/libfeaclient/netlink_head.cc io_event ] NetlinkHead::io_event, error on RTM_NEWADDR Feb 26 11:00:52 localhost xorp_fea: [ 2008/02/26 11:00:52 WARNING xorp_fea FEA ] Got update for interface not in libfeaclient tree: eth1 Feb 26 11:00:52 localhost heartbeat[14979]: WARN: Cluster node router1 returning after partition. Feb 26 11:00:52 localhost heartbeat[14979]: WARN: Cluster node router1 returning after partition. Feb 26 11:00:52 localhost heartbeat[14979]: WARN: Deadtime value may be too small. Feb 26 11:00:52 localhost heartbeat[14979]: WARN: 28 lost packet(s) for [router1] [244:273] Feb 26 11:00:52 localhost heartbeat[14979]: WARN: Late heartbeat: Node router1: interval 51500 ms Feb 26 11:00:53 localhost xorp_fea: [ 2008/02/26 11:00:53 WARNING xorp_fea FEA ] Got update for interface not in libfeaclient tree: eth0 Feb 26 11:00:54 localhost xorp_fea: [ 2008/02/26 11:00:54 WARNING xorp_fea FEA ] Got update for interface not in libfeaclient tree: eth0.XXX Feb 26 11:00:54 localhost xorp_fea: [ 2008/02/26 11:00:54 WARNING xorp_fea FEA ] Got update for interface not in libfeaclient tree: eth0.YYY Feb 26 11:00:54 localhost xorp_fea: [ 2008/02/26 11:00:54 WARNING xorp_fea FEA ] Got update for interface not in libfeaclient tree: eth0.ZZZ Feb 26 11:00:54 localhost heartbeat: WARN: IP Address XXX.XXX7.XXX.1 NOT released Feb 26 11:00:54 localhost heartbeat: ERROR: Return code 255 from /etc/ha.d/resource.d/IPaddr Feb 26 11:00:55 localhost heartbeat: WARN: IP Address XXX.XXX7.XXX.1 NOT released Feb 26 11:00:55 localhost heartbeat: ERROR: Return code 255 from /etc/ha.d/resource.d/IPaddr Feb 26 11:00:56 localhost heartbeat: WARN: IP Address XXX.XXX7.XXX.1 NOT released Feb 26 11:00:57 localhost heartbeat: ERROR: Return code 255 from /etc/ha.d/resource.d/IPaddr router1 log: Feb 26 10:49:53 localhost xorp_static_routes: [ 2008/02/26 10:49:53 ERROR xorp_static_routes:4194 LIBFEACLIENT +228 /home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/libfeaclient/netlink_head.cc io_event ] NetlinkHead::io_event, error on RTM_NEWADDR Feb 26 10:49:53 localhost xorp_rib: [ 2008/02/26 10:49:53 ERROR xorp_rib:4155 LIBFEACLIENT +228 1 /home/autobuild/builds/master/2007-10-24-0001/ofr/xorp/xorp/libfeaclient/netlink_head.cc io_event ] NetlinkHead::io_event, error on RTM_NEWADDR Feb 26 10:49:55 localhost heartbeat: WARN: IP Address XXX.XXX.XXX.61 NOT released Feb 26 10:49:55 localhost heartbeat: ERROR: Return code 255 from /etc/ha.d/resource.d/IPaddr Feb 26 10:49:56 localhost heartbeat: WARN: IP Address XXX.XXX.XXX.61 NOT released Feb 26 10:49:56 localhost heartbeat: ERROR: Return code 255 from /etc/ha.d/resource.d/IPaddr Feb 26 10:49:58 localhost heartbeat: WARN: IP Address XXX.XXX.XXX.61 NOT released Feb 26 10:49:58 localhost heartbeat: ERROR: Return code 255 from
Re: [Vyatta-users] Clustering Causes Reboots
Hi Ben, I'm pretty sure that the clustering mechanism will reboot a system as a last resort if it is unable to stop a resource. What resources do you have in your cluster? I suppose this could be hardware related if the systems (and their specific NICs) are having a difficult time relinquishing ownership the cluster IP address for some reason. All cluster (HA) related error messages should be reported in /var/log/messages. Do you see any errors reported when you look at the logs? -Robyn Justin Fletcher wrote: No, that's not intentional ;-) I haven't seen that before either - is there any information in the log files, or from show cluster status? Do you end up in a split-brain situation where the two systems can't exchange heartbeats? The reboot-on-panic option takes effect on kernel panic, so it shouldn't affect you here. Justin On Sun, Feb 24, 2008 at 2:55 PM, Ben Speckien [EMAIL PROTECTED] wrote: Hello I've been playing with clustering on VC3 (10/29/07) and I can't get it to work well. It seems that when one router moves from secondary to primary one or both router have to reboot. Is this supposed to happen? Furthermore, if I disconnect the secondary router the primary router or both routers reboot when I reconnect the secondary router. I have set system options reboot-on-panic to false. It doesn't seem like the auto-failback option does anything and sometimes the primary router reboots every time I try to set it to true. Does the hardware make a difference? Thanks, Ben ___ 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] Need advise on how to setup BGP with 4 links
ken Felix wrote: Hi, yongsan You need to look at a IBGP mesh between the 2 routers on the different floor. You will configure each one as an Bgp-neighbor but the remote-asn would be that of your assigned ASN. I would search on cisco website if the vyatta documentation doesn't shows this example. You can easily create this within minutes. Actually, this exact example starts on page 132 (chapter 11) of the Vyatta VC3 Configuration Guide. There's a diagram that includes 4 routers in an iBGP mesh connecting to 2 external eBGP peers. All configuration commands necessary to get this particular network up and running are included on the pages following the diagram. So, there'll be no need to search the Cisco website! ;-) -Robyn ___ 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] firewall help
Hi Alain,
Take a look at this post:
http://mailman.vyatta.com/pipermail/vyatta-users/2007-November/002406.html
It looks like you're running into bug 2502, which has been fixed in our
most recent set of updates and will no longer be an issue in the next
release.
The link above has more information on the bug and an easy workaround so
you can specify all in rule 10.
Thank you,
Robyn
Alain Kelder wrote:
Wondering if someone could help me with my firewall rules. At this
point, I'm just firewalling local traffic. My objective is drop
everything other than SSH and even then only allow SSH from for a
handful of hosts.
So for eth0 (my WAN interface), I added:
firewall {
local {
name: WAN-to-LOCAL
}
}
}
And then the following firewall rules:
firewall {
log-martians: enable
send-redirects: disable
receive-redirects: disable
ip-src-route: disable
broadcast-ping: disable
syn-cookies: enable
name WAN-to-LOCAL {
description: Inbound traffic to router
rule 10 {
description: Accept established and related
protocol: tcp
state {
established: enable
related: enable
}
action: accept
log: disable
}
rule 20 {
description: Accept SSH
protocol: tcp
state {
established: enable
related: enable
new: enable
invalid: disable
}
action: accept
log: enable
source {
address: XXX.XXX.XXX.XXX
}
destination {
port-number 22
}
}
rule 21 {
description: Accept SSH
protocol: tcp
state {
established: enable
related: enable
new: enable
invalid: disable
}
action: accept
log: enable
source {
network: XXX.XXX.XXX.XXX/28
}
destination {
port-number 22
}
}
}
}
I'm pretty sure something isn't right with my rule 10 (established and
related). For one thing, Vyatta complains if I set protocol to all.
Says only tcp is allowed when packet state is defined. So what should
I do about UDP? I do need to allow related and established, right?
I don't need to limit outgoing traffic, but is it a good idea to have
rules for inbound traffic if I'm doing NAT?
___
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] IPSec Termination
Hi Carlos, I'm not sure I'm correctly understanding your reason for using aggressive mode but, are you sure that the other end of the connection is expecting an aggressive mode negotiation? If your only special requirement is that the other end of the connection is being initiated from an unknown peer address, then simply setting the peer to 0.0.0.0, which it looks like you've done, should work for you. Either way, I don't think your phase 1 negotiation will complete if only one end is set to aggressive mode. This may be the reason for the INVALID_ID error. Have you tried connecting with aggrmode=no? If none of the above apply to your situation, can you reply with the VPN configuration on the remote end? Also, what type of device is it? Thanks! Robyn Dunmoodie, Carlos wrote: Here's my config conn peer-0.0.0.0-tunnel-1 left=1.1.1.1 right=%any leftsubnet=192.168.12.0/24 rightsubnet=192.168.10.0/24 rekey=no ike=3des-sha1,3des-sha1 ike=3des-sha1,3des-sha1 ikelifetime=3600s aggrmode=yes esp=3des-md5,3des-sha1 keylife=1800s rekeymargin=540s type=tunnel pfs=yes compress=no authby=secret auto=add From the initiator I get an error message INVALID_ID INFORMATION How do you configure the user id to match the userid from the initiator, or does that matter? Also does the above config look accurate for an aggressive mode. When I configure auto=ignore I see no IPSEC information When I change auto=add, I see the IPSEC negotiations, and it doesn't initiate, which is good. But tunnel not established Carlos Dunmoodie Network Engineer Engineering Office: (301) 944-2896 Cell: (443) 864-9822 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ken Felix Sent: Monday, February 04, 2008 7:32 PM To: vyatta-users@mailman.vyatta.com Subject: [Vyatta-users] IPSec Termination Couldn't you get the same thing with the VPN dead peer-detect set to HOLD? Under strongswan for example, their's a setting that would allow you to auto=start or auto=ignore, if you could add this, you should be okay. Here's how my vyatta ipsec.conf looks; If the last line was set to auto=ignore, than I would think ipsec would be started and the host would wait for the far-end ( right ) to initiated the session. ___ 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] BGP Policy Generic Route Distribution
Hi Shane, Try configuring a host address on the loopback interface and then creating a static route for your /24 with a next-hop of your loopback address. Then you would export static with a 'from network4 x.x.x.x/24' statement. If you do this, you should also remove the term that is exporting connected. Thank you, Robyn Shane McKinley wrote: I have tested the Vyatta once again being an inch away from totally replacing my Cisco core router. BGP connection and route policy are working, but with a problem. It seems that the BGP routing table is redistributing my exact routes as specified in the policy configuration. = set policy policy-statement NAME term 1 from protocol connected set policy policy-statement NAME term 1 then action accept set policy policy-statement NAME term 2 from protocol static set policy policy-statement NAME term 2 then action accept = My router's function is to distribute routes to the 'world'. I am not wanting to redistribute my exact connected or static routes, but a generic class C distribution of all my owned subnets. Is it possible to modify what is being sent in the BGP routing table with out manually modifying all my connected and static routes? My upstream provider only allows X.X.X.X/24 BGP advertisements. Any help on this situation is appreciated and the world will be with one less Cisco router. 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] VC3 firewall problem
Hi Abhilash,
There is an issue in VC3 that restricts the related/ established rule
(your rule number 1) to TCP only. Most likely, the reason your VC2
firewall was working is because return traffic of any type (ICMP, UDP,
TCP, etc.) was allowed back in via rule number 1. Your new rule number
1 on VC3 only allows return traffic on TCP.
For more information on the bug and to fix this issue on your system,
see the following post to the user's list:
http://mailman.vyatta.com/pipermail/vyatta-users/2007-November/002406.html
This bug has been fixed and will no longer be an issue in the next release.
Thank you,
Robyn
abhilash s wrote:
Hi All,
I have upgraded VC2 to VC3. But when I tried to implement
firewall, all traffic to internet stops. Here is my old and new
firewall configuration:
OLD FIREWALL CONFIGURATION:
firewall {
log-martians: enable
send-redirects: disable
receive-redirects: disable
ip-src-route: disable
broadcast-ping: disable
syn-cookies: enable
name inbound {
rule 1 {
protocol: all
state {
established: enable
related: enable
}
action: accept
log: disable
}
rule 2 {
protocol: tcp
action: accept
log: disable
source {
address: x.x.x.x
}
destination {
port-name: ssh
}
}
rule 3 {
protocol: tcp
action: accept
log: disable
source {
address: x.x.x.x
}
destination {
port-name: ssh
}
}
rule 4 {
protocol: icmp
icmp {
type: 8
}
action: accept
log: disable
}
rule 5 {
protocol: icmp
icmp {
type: 11
}
action: accept
log: disable
}
rule 6 {
protocol: udp
action: accept
log: disable
destination {
port-number: xxx
}
}
rule 7 {
protocol: all
action: drop
log: disable
source {
network: 0.0.0.0/0
}
}
}
}
NEW FIREWALL CONFIGURATION:
firewall {
log-martians: enable
send-redirects: disable
receive-redirects: disable
ip-src-route: disable
broadcast-ping: disable
syn-cookies: enable
name inbound {
description: inbound firewall
rule 1 {
protocol: tcp
state {
established: enable
related: enable
}
action: accept
log: disable
}
rule 2 {
protocol: tcp
action: accept
log: disable
source {
address: x.x.x.x
}
destination {
port-name ssh
}
}
rule 3 {
protocol: tcp
action: accept
log: disable
source {
address: x.x.x.x
}
destination {
port-name ssh
}
}
rule 4 {
protocol: icmp
icmp {
type: 8
}
action: accept
log: disable
}
rule 5 {
protocol: icmp
icmp {
type: 11
}
action: accept
log: disable
}
rule 6 {
protocol: udp
action: accept
log: disable
destination {
port-number xxx
}
}
rule 7 {
protocol: udp
action: accept
log: disable
destination {
port-number xxx
}
}
rule 8 {
protocol: all
action: drop
log: disable
source {
network: 0.0.0.0/0
}
}
}
}
I have applied this setting to my interface's firewall as : in and local .
When I try to enable this firewall setting , I can't ping to my ISP
gateway (modem IP) too.
Please tell me what I want to change to implement it on VC3 ?
Thanks in Advance,
Regards,
Abhilash S
___
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
Re: [Vyatta-users] Advises on configuring BGP
Hi, It's your ISPs responsibility to advertise your prefix to its upstream peers. I don't see your prefix on the Internet so your ISP needs to verify that they are advertising your prefix and that they have added it in to their prefix lists etc. So basically, if they are receiving it from you, then it's on them to make your prefix available to the rest of the world. You should contact them and let them know that your prefix is unavailable beyond their AS. Thank you, Robyn Poh Yong Hwang wrote: Hi, Sorry for the misunderstanding. The ip 11.11.11.12 http://11.11.11.12 is just an example that I stated. My actual ip address is 117.120.0.0/21 http://117.120.0.0/21. I have check with my upstream regarding this and they said they have recieve 1 prefix from my router: sgw-rs1# sh ip bgp nei 202.79.197.25 http://202.79.197.25 received-routes BGP table version is 0, local router ID is 202.79.197.126 http://202.79.197.126 Status codes: s suppressed, d damped, h history, * valid, best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 117.120.0.0/21 http://117.120.0.0/21 202.79.197.25 http://202.79.197.250 0 7595 ? Total number of prefixes 1 I see that under the Path, it stated as ? which is incomplete. Could that be the issue for not able to find the path back to my router? Thanks On Jan 7, 2008 11:07 PM, Robyn Orosz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, If 11.11.11.12/21 http://11.11.11.12/21 is your own IP space (which I doubt because it's allocated to the DoD) ;-) and your service provider is receiving it via BGP and propagating it out to the Internet, then you should be able to reach it from the outside. So I guess what I'm not clear on is, are you literally setting eth1 to 11.11.11.12 http://11.11.11.12? Or, is this number supposed to represent your actual IP space? If you have your actual owned IP space assigned to eth1 and you are unable to reach it externally, then make sure that it is still being exported to your BGP peer and that they are advertising it outside of their AS to the Internet. Try performing an external traceroute to your eth1 IP from somewhere like traceroute.org http://traceroute.org or some other external location. You can also access public route servers on traceroute.org http://traceroute.org and run a 'show ip bgp your-ip-address to see if your prefix has been advertised out to the Internet. Thank you, Robyn Poh Yong Hwang wrote: Hi, I tried to add a ip address 11.11.11.12 http://11.11.11.12 http://11.11.11.12 http://11.11.11.12 with prefix length of 21 to eth1. But i still cannot remote access or ping to this ip address from outside. I hope to able to access the web gui of Vyatta remotely using the eth1 ip address. Also this eth1 will be link to a switch and to the rest of the servers, so am I right to set all the servers default gateway to be 11.11.11.12 http://11.11.11.12 http://11.11.11.12 which is the ip address of the eth1? thanks for all your patience On Jan 4, 2008 10:25 PM, Robyn Orosz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I'm glad to hear you have it working now. Since you are exporting your aggregate (/21) via a static route to your loopback interface, you don't have to assign the entire /21 to eth1. You can segment it in whatever way you choose as it will still always be exported as a /21 based on your existing policy. Basically, you can set whatever IP and prefix length you want on your eth1 as long as it is a valid part of your /21 aggregate prefix. Thank you, Robyn Poh Yong Hwang wrote: Hi all, Sorry for getting back so late as I am tied up with some other stuffs.. Thanks for all the advice and my upstream managed to see my prefix. Seems that changing the next hop to my eth0 public ip address did the trick. Now as my eth0 is connected to my upstream, what IP address should I set on my eth1? It will be connected to a layer 3 switch (core switch) which all our servers will be connected to that switch. I have a /21 range of ip addresses, so should I just use the first ip to set on eth1? What prefix-length should I set on that as well? Please advise
Re: [Vyatta-users] Advises on configuring BGP
Hi,
I'm glad to hear you have it working now.
Since you are exporting your aggregate (/21) via a static route to your
loopback interface, you don't have to assign the entire /21 to eth1.
You can segment it in whatever way you choose as it will still always be
exported as a /21 based on your existing policy. Basically, you can set
whatever IP and prefix length you want on your eth1 as long as it is a
valid part of your /21 aggregate prefix.
Thank you,
Robyn
Poh Yong Hwang wrote:
Hi all,
Sorry for getting back so late as I am tied up with some other
stuffs.. Thanks for all the advice and my upstream managed to see my
prefix. Seems that changing the next hop to my eth0 public ip address
did the trick.
Now as my eth0 is connected to my upstream, what IP address should I
set on my eth1? It will be connected to a layer 3 switch (core switch)
which all our servers will be connected to that switch. I have a /21
range of ip addresses, so should I just use the first ip to set on
eth1? What prefix-length should I set on that as well?
Please advise.
Thanks!
On Dec 20, 2007 1:52 AM, Robyn Orosz [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi There,
The next-hop value is providing the peer with the next-hop value
to use
for the advertised prefixes from your router. So, the next-hop should
be an address on your router. It looks correct based on your edited
configuration file.
If you run a 'show bgp peers' it will show you whether or not your
session is established with your peer. If it's not established, that
would be one reason why the ISP claims they did not receive a prefix
advertisement from you. First off, verify your configuration is
correct
(IPs, ASNs etc). Then you can run a tshark on eth0 (your BGP peering
interface) on port 179 (tshark -i eth0 port 179 -Vn) to take a
look at
the BGP packets and also take a look at the logs 'show log.'
If your session is established, make sure the route you are
advertising
with your policy exists in the routing table and matches the
prefix in
the policy. You can check the route by running a 'show route protocol
static.' You must see the static route that you've pointed to your
loopback interface in the table. If it's not there, verify your
configuration etc.
If it is there, make sure the prefix in your policy matches the route
exactly. If it does not match, it won't be advertised.
If all of the above are correct, take a look at 'show bgp route' and
make sure you see your advertised prefix in the output. If it's there
then your ISP is probably rejecting your advertisement. They need to
add your prefix to their prefix list. ISPs forget to add their
customer's prefixes to their prefix lists all the time.
The loopback address for the BGP ID won't hurt anything but Ahsan is
correct that for eBGP peering with external public peers, you should
probably set your BGP ID to your public IP on eth0.
Thanks! and I hope this helps.
-Robyn
Ahsan Khan wrote:
Hi,
I think your nexthop IP should be your ISP IP address and
not your
own. Also check with your ISP if they can confirm about BGP session
establishment, Most router like Juniper, Cisco can explain a lot
in their
output the reasons if the session is not established.
Also loopback IP is normally used in BGP if you have multiple
interfaces
connected to same ISP, or you are using some other complex
configuration. I
would use interface IP connected to ISP to avoid routing issues
etc.
Thanks.
Ahsan Khan
-Original Message-
From: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]] On Behalf Of Poh
Yong Hwang
Sent: Tuesday, December 18, 2007 11:20 PM
To: Justin Fletcher
Cc: vyatta-users
Subject: Re: [Vyatta-users] Advises on configuring BGP
Hi,
Thanks. I just could not traceroute to the router and according
to my
peering upstream, they mention that they did not receive any of
my prefix
announcement.
Basically i just want to do a simple setup at this moment with
one box
running Vyatta and eth0 is link to one of our upstream provider
which we
want to peer with. I have my ASN number as well as a /21 range
of IP
addresses to announce. Here is my configuration:
loopback ip : 10.0.0.65 http://10.0.0.65
My ASN : 100
My IP Range : XX.XX.XX.XX/21
Upstream Route IP : a.b.c.d
Customer Interface IP : c.d.e.f
Upstream ASN : 200
protocols {
bgp {
bgp-id: 10.0.0.65 http://10.0.0.65
local
Re: [Vyatta-users] Can't install in hard drive - it's working...
FYI... It's also been added to the bug database and will hopefully be suppressed in the future: Bug # - 2536 Title - Enhancement: Suppress FATAL Wanpipe error message displayed in console boot messages https://bugzilla.vyatta.com/show_bug.cgi?id=2536 Thanks, Robyn Aubrey Wells wrote: 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 http://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. http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com mailto: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] Advises on configuring BGP
Hi There,
The next-hop value is providing the peer with the next-hop value to use
for the advertised prefixes from your router. So, the next-hop should
be an address on your router. It looks correct based on your edited
configuration file.
If you run a 'show bgp peers' it will show you whether or not your
session is established with your peer. If it's not established, that
would be one reason why the ISP claims they did not receive a prefix
advertisement from you. First off, verify your configuration is correct
(IPs, ASNs etc). Then you can run a tshark on eth0 (your BGP peering
interface) on port 179 (tshark -i eth0 port 179 -Vn) to take a look at
the BGP packets and also take a look at the logs 'show log.'
If your session is established, make sure the route you are advertising
with your policy exists in the routing table and matches the prefix in
the policy. You can check the route by running a 'show route protocol
static.' You must see the static route that you've pointed to your
loopback interface in the table. If it's not there, verify your
configuration etc.
If it is there, make sure the prefix in your policy matches the route
exactly. If it does not match, it won't be advertised.
If all of the above are correct, take a look at 'show bgp route' and
make sure you see your advertised prefix in the output. If it's there
then your ISP is probably rejecting your advertisement. They need to
add your prefix to their prefix list. ISPs forget to add their
customer's prefixes to their prefix lists all the time.
The loopback address for the BGP ID won't hurt anything but Ahsan is
correct that for eBGP peering with external public peers, you should
probably set your BGP ID to your public IP on eth0.
Thanks! and I hope this helps.
-Robyn
Ahsan Khan wrote:
Hi,
I think your nexthop IP should be your ISP IP address and not your
own. Also check with your ISP if they can confirm about BGP session
establishment, Most router like Juniper, Cisco can explain a lot in their
output the reasons if the session is not established.
Also loopback IP is normally used in BGP if you have multiple interfaces
connected to same ISP, or you are using some other complex configuration. I
would use interface IP connected to ISP to avoid routing issues etc.
Thanks.
Ahsan Khan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Poh Yong Hwang
Sent: Tuesday, December 18, 2007 11:20 PM
To: Justin Fletcher
Cc: vyatta-users
Subject: Re: [Vyatta-users] Advises on configuring BGP
Hi,
Thanks. I just could not traceroute to the router and according to my
peering upstream, they mention that they did not receive any of my prefix
announcement.
Basically i just want to do a simple setup at this moment with one box
running Vyatta and eth0 is link to one of our upstream provider which we
want to peer with. I have my ASN number as well as a /21 range of IP
addresses to announce. Here is my configuration:
loopback ip : 10.0.0.65
My ASN : 100
My IP Range : XX.XX.XX.XX/21
Upstream Route IP : a.b.c.d
Customer Interface IP : c.d.e.f
Upstream ASN : 200
protocols {
bgp {
bgp-id: 10.0.0.65
local-as: 100
import:
export: BGP_EXPORT
peer a.b.c.d {
import:
export:
multihop: 1
peer-port: 179
local-port: 179
local-ip: c.d.e.f
as: 9989
next-hop: c.d.e.f
holdtime: 90
delay-open-time: 0
client: false
confederation-member: false
disable: false
ipv4-unicast: true
ipv4-multicast: false
ipv6-unicast: false
ipv6-multicast: false
md5-key:
}
}
static {
disable: false
route XX.XX.XX.XX/21 {
next-hop: 10.0.0.65
metric: 1
}
}
}
policy {
policy-statement BGP_EXPORT {
term 1 {
from {
protocol: static
network4: XX.XX.XX.XX/21
}
then {
action: accept
}
}
}
}
interfaces {
restore: false
loopback lo {
description:
address 10.0.0.65 {
prefix-length: 32
disable: false
}
}
ethernet eth0 {
disable: false
discard: false
description:
hw-id: 00:30:48:55:63:FC
duplex: auto
speed: auto
address c.d.e.f {
prefix-length: 25
disable: false
}
Re: [Vyatta-users] Routing Policy Confusion
Hi Shane,
First off, in your BGP peer configuration, you're telling your peer that
the next-hop to reach your prefixes is itself. So, anything the peer
receives from you will have a next-hop of ZZZ.ZZZ.ZZZ.ZZZ (which would
be the peer's IP address). Under most circumstances, you would not want
to do this. You'd want to change the next-hop value to an address on
your own device (most likely this would be the same IP as your
local-ip). So based on your configuration below, you'd set the next-hop
to XXX.XXX.XXX.XXX.
The policy is exporting all routes learned from BGP to your BGP peers
and marking the next-hops of these routes as ZZZ.ZZZ.ZZZ.ZZZ (based on
the config below). So, if you're receiving routes from your peer on
ZZZ.ZZZ.ZZZ.ZZZ, your policy is sending them back to your peer and
telling the peer that in order to reach the routes it should use itself
as the next-hop. If you need to advertise a prefix that is originating
from your AS, you are not going to be able to do this with your existing
policy.
You need to advertise routes from an IGP (such as connected or static)
on your router. If you have the prefix that you want to advertise
configured on eth1, for example, you can configure a policy that exports
your connected route. It would look something like:
policy-statement BGP_Export {
term 1 {
from {
protocol: connected
network4: 192.168.0.0/24 -This is representing the
prefix you wish to advertise
}
then {
action: accept
}
}
}
If your prefix is originating from a different IGP such as ospf or
static, you'd configure the policy as 'from protocol ospf4' or 'from
protocol static' etc.
I hope this clarifies things a bit.
Thank you,
Robyn
Shane McKinley wrote:
I would like to be able to specify which BGP routes get exported,
specifically. From what I understand, policies are the way to go about
this.
If someone could take the liberty to explain exactly what the statement
below achieves I would be greatful:
policy-statement Next_Hop_Self {
term 1 {
from {
protocol: bgp
}
then {
nexthop4: ZZZ.ZZZ.ZZZ.ZZZ
}
}
}
bgp-id: XXX.XXX.XXX.XXX
local-as: 1234
export: Next_Hop_Self
peer ZZZ.ZZZ.ZZZ.ZZZ {
local-ip: XXX.XXX.XXX.XXX
as: 4321
next-hop: ZZZ.ZZZ.ZZZ.ZZZ
}
What exactly is this configuration achieving and how would I throw in
this mix to specify exactly what routes to export to the peer
ZZZ.ZZZ.ZZZ.ZZZ? I wouldn't want to export my default gateway; I could
only imagine what kind of havoc that would create.
I have read the configuration guide on policies, but I am still
confused.
Please help build my confidence in Vyatta routing policies,
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] VRRP Configuration Problem
Hi Jim,
I'm glad you were able to resolve this by changing the link speed.
The disable-vmac option was just added recently and is available via the
community testing repository (sorry...I forgot to mention that). This
option sets the vrrpd -n flag. If you'd prefer not to upgrade to latest
testing packages, starting vrrpd from the command line using the -n
flag should also resolve this issue.
EX: /opt/vyatta/sbin/vrrpd -i eth0 -v 20 -p 1 -d 1 10.4.0.200 -n
If you'd like to upgrade to obtain access to this new feature, here are
some instructions on how to do this:
http://www.vyatta.com/twiki/bin/view/Community/HowToUpdate
You would set your repository component as follows:
set system package repository community component testing main
You're absolutely correct about the documentation. The documents were
released prior to the availability of the disable-vmac option. I'll let
our technical writer know that this needs to be added. Thank you for
noticing this. ;-)
-Robyn
Jim K wrote:
That definitely seems to be the issue as setting the ports to 100Mb seems to
solve the problem.
The disable-vmac setting does not seem to work nor is it listed in the
documentation
set interfaces ethernet eth0 vrrp disable-vmac true
ERROR: path interfaces ethernet eth0 vrrp disable-vmac is not valid.
turning their LAN interfaces on and off as they switch == link state going
up and down
Thanks.
- Original Message
From: Robyn Orosz [EMAIL PROTECTED]
To: Jim K [EMAIL PROTECTED]
Cc: Vyatta-users@mailman.vyatta.com
Sent: Friday, December 7, 2007 1:49:20 PM
Subject: Re: [Vyatta-users] VRRP Configuration Problem
Hi Jim,
I'm not totally sure what you mean by turning their LAN interfaces on
and off as they switch but, it sounds like the following bug:
https://bugzilla.vyatta.com/show_bug.cgi?id=2350 - bug 2350
See comment number 4 which basically tells you to disable the vmac:
set interfaces ethernet eth0 vrrp disable-vmac true
Thank you,
Robyn
Jim K wrote:
I'm been trying to configure a backup router using VRRP, but after retrying
all the obvious, I've run out of options.
After configuring both the MASTER and SLAVE as below, both switch from
MASTER to SLAVE mode, and subsequently are turning their LAN interfaces on
and off as they switch from either mode.
Neither router seems to detect the others multicast VRRP broadcast, even
though they are both connected to the same VLAN on the same switch (Catalyst
2960).
Configuration below
-
MASTER router
}
ethernet eth0
hw-id: 00:1c:32:ce:7b:50
address xxx.xxx.204.253
prefix-length:24
}
vrrp {
vrrp-group: 204
virtual-address: xxx.xxx.204.1
priority: 150
}
}
ethernet eth1
hw-id: 00:1c:32:ce:7b:A1
address xxx.xxx.102.59
prefix-length:24
}
vrrp {
vrrp-group: 102
virtual-address: xxx.xxx.102.2
priority: 150
}
}
SLAVE router
}
ethernet eth0
hw-id: 00:1c:32:ce:7b:64
address xxx.xxx.204.254
prefix-length:24
}
vrrp {
vrrp-group: 204
virtual-address: xxx.xxx.204.1
priority: 10
}
}
ethernet eth1
hw-id: 00:1c:32:ce:7b:77
address xxx.xxx.102.60
prefix-length:24
}
vrrp {
vrrp-group: 102
virtual-address: xxx.xxx.102.2
priority: 10
}
}
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
___
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
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
___
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] VRRP Configuration Problem
Hi Jim,
I'm not totally sure what you mean by turning their LAN interfaces on
and off as they switch but, it sounds like the following bug:
https://bugzilla.vyatta.com/show_bug.cgi?id=2350 - bug 2350
See comment number 4 which basically tells you to disable the vmac:
set interfaces ethernet eth0 vrrp disable-vmac true
Thank you,
Robyn
Jim K wrote:
I'm been trying to configure a backup router using VRRP, but after retrying
all the obvious, I've run out of options.
After configuring both the MASTER and SLAVE as below, both switch from MASTER
to SLAVE mode, and subsequently are turning their LAN interfaces on and off
as they switch from either mode.
Neither router seems to detect the others multicast VRRP broadcast, even
though they are both connected to the same VLAN on the same switch (Catalyst
2960).
Configuration below
-
MASTER router
}
ethernet eth0
hw-id: 00:1c:32:ce:7b:50
address xxx.xxx.204.253
prefix-length:24
}
vrrp {
vrrp-group: 204
virtual-address: xxx.xxx.204.1
priority: 150
}
}
ethernet eth1
hw-id: 00:1c:32:ce:7b:A1
address xxx.xxx.102.59
prefix-length:24
}
vrrp {
vrrp-group: 102
virtual-address: xxx.xxx.102.2
priority: 150
}
}
SLAVE router
}
ethernet eth0
hw-id: 00:1c:32:ce:7b:64
address xxx.xxx.204.254
prefix-length:24
}
vrrp {
vrrp-group: 204
virtual-address: xxx.xxx.204.1
priority: 10
}
}
ethernet eth1
hw-id: 00:1c:32:ce:7b:77
address xxx.xxx.102.60
prefix-length:24
}
vrrp {
vrrp-group: 102
virtual-address: xxx.xxx.102.2
priority: 10
}
}
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
___
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 relay
default) Source: MAC (MacRouterEth2) Address: MacRouterEth2 (0MacRouterEth2) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factorydefault) Type: IP (0x0800) Internet Protocol, Src: 192.168.2.10 http://192.168.2.10 (192.168.2.10 http://192.168.2.10), Dst: 192.168.2.196 http://192.168.2.196 (192.168 .2.196) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00) 0001 00.. = Differentiated Services Codepoint: Unknown (0x04) ..0. = ECN-Capable Transport (ECT): 0 ...0 = ECN-CE: 0 Total Length: 328 Identification: 0x (0) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 16 Protocol: UDP (0x11) Header checksum: 0x2377 [correct] [Good: True] [Bad : False] Source: 192.168.2.10 http://192.168.2.10 (192.168.2.10 http://192.168.2.10) Destination: 192.168.2.196 http://192.168.2.196 (192.168.2.196 http://192.168.2.196) User Datagram Protocol, Src Port: 67 (67), Dst Port: 68 (68) Source port: 67 (67) Destination port: 68 (68) Length: 308 Checksum: 0x9f16 [correct] Bootstrap Protocol Message type: Boot Reply (2) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x3c080bf9 Seconds elapsed: 0 Bootp flags: 0x (Unicast) 0... = Broadcast flag: Unicast .000 = Reserved flags: 0x Client IP address: 0.0.0.0 http://0.0.0.0 (0.0.0.0 http://0.0.0.0) Your (client) IP address: 192.168.2.196 http://192.168.2.196 (192.168.2.196 http://192.168.2.196) Next server IP address: 192.168.2.2 http://192.168.2.2 (192.168.2.2 http://192.168.2.2) Relay agent IP address: 192.168.2.10 http://192.168.2.10 ( 192.168.2.10 http://192.168.2.10) Client MAC address: X () Server host name not given Boot file name not given Magic cookie: (OK) Option: (t=53,l=1) DHCP Message Type = DHCP Offer Option: (53) DHCP Message Type Length: 1 Value: 02 Option: (t=1,l=4) Subnet Mask = 255.255.255.0 http://255.255.255.0 Option: (1) Subnet Mask Length: 4 Value: FF00 Option: (t=58,l=4) Renewal Time Value = 4 days Option: (58) Renewal Time Value Length: 4 Value: 00054600 Option: (t=59,l=4) Rebinding Time Value = 7 days Option: (59) Rebinding Time Value Length: 4 Value: 00093A80 Option: (t=51,l=4) IP Address Lease Time = 8 days Option: (51) IP Address Lease Time Length: 4 Value: 000A8C00 Option: (t=54,l=4) Server Identifier = 192.168.2.2 http://192.168.2.2 Option: (54) Server Identifier Length: 4 Value: C0A80202 Option: (t=3,l=4) Router = 192.168.2.1 http://192.168.2.1 Option: (3) Router Length: 4 Value: C0A80201 Option: (t=6,l=4) Domain Name Server = 192.168.2.2 http://192.168.2.2 Option: (6) Domain Name Server Length: 4 Value: C0A80202 Option: (t=44,l=4) NetBIOS over TCP/IP Name Server = 192.168.2.2 http://192.168.2.2 Option: (44) NetBIOS over TCP/IP Name Server Length: 4 Value: C0A80202 Option: (t=46,l=1) NetBIOS over TCP/IP Node Type = H-node Option: (46) NetBIOS over TCP/IP Node Type Length: 1 Value: 08 End Option Padding But I have no Frame message if I request a new ip from the network eth0 Thanks for your help Damien On Dec 6, 2007 10:41 PM, Robyn Orosz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Damien, This should work as long as requests are coming in from hosts that are connected to eth0. Is there more than one network assigned to eth0? It would help if you could post your configuration (you can block out any public IPs). If you run a verbose packet capture, you should be able to see what the relay agent IP is in the request packet. If it's something other than 192.168.10.x or 192.168.2.x (your 2 scopes), the Windows server is not going to serve an address to it. Try running: tshark -i eth2 port 67 and port 68 -Vn Thanks, Robyn Dams wrote: Thanks for your reply. Sorry, my mistake : not eth1 but eth0. ( 192.168.10.X) Eth2 - network with the DHCP Server on network 192.168.2.XXx The DHCP serve the scope (192.168.2.0 http://192.168.2.0 http://192.168.2.0
Re: [Vyatta-users] bgp not using advertised next-hop
Hi Aubrey, I'll find out from Rick, the developer here who works with the serial integration, if there is a preferred method for scripting this. I'll reply back to this list when I speak with him. I would just copy the files into /etc/wanpipe and run a wanrouter restart on boot. You should remove them from the config if you do this. As far as a permanent solution, Rick tells me that PPPD will not create routes with prefixes other than /32. I'm thinking the solution right now is to only use PPPD for MLPPP and continue to use the Sangoma driver for PPP w/o MLPPP. I'm sure they (the developers) will think of something. To help get the thinking started, I've bumped up the priority on the bug. So for now, Rick doesn't have a better solution than the one I gave you. Sorry :-( -Robyn Aubrey Wells wrote: That worked perfectly. All my routes point to the correct place and BGP doesn't hate me now. :-) Let me know if you figure out a more permanent solution, but this will work for now. I'm assuming I need to remove all the serial config from vyatta to keep my changes to the configs from being overwritten? Or will I need to script out some sed commands and restart wanrouter from rc.local on boot regardless of what's in the vyatta config? -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Nov 30, 2007, at 5:05 PM, Robyn Orosz wrote: Hi Aubrey, Thanks for trying that and I'm sorry it still didn't resolve the issue. This problem does not exist in pre-VC3 versions. With your configuration as it is, everything should work fine in 2.2. If you need to use VC3, you can kill the pppd process and reconfigure the Sangoma driver to run PPP. I'm still looking into another way to manipulate pppd so that it will accept a netmask value but if you'd like to try the Sangoma workaround you'll need to: 1. Edit the /etc/wanpipe/wanpipe1.conf file: change: wan0.1 = wanpipe1, 0, TTY, tty, wan0.tty to wan0.1 = wanpipe1, 1, WANPIPE, ppp, wan0.ppp then change: [wan1.tty] to [wan0.ppp] PAP = NO CHAP = NO 2. Edit the /etc/wanpipe/interfaces/wan0.1 file: It should be empty so you'll need to add: DEVICE=wan0.1 IPADDR=64.211.X.34 NETMASK=255.255.255.252 POINTOPOINT=64.211.X.33 ONBOOT=yes 3. Then run a 'wanrouter restart' I tested this here and it worked for me by bringing the wan0.1 /30 route into the xorp routing table. If you do decide to use VC3 and run ppp via the Sangoma driver, all of the above will need to be scripted so it will be re-added on boot. I know this is not the best workaround but give it a try if you're up to it and I'll still see if I can come up with anything better in the mean time. Thanks, Robyn Aubrey Wells wrote: Adding it from the shell gets the /30 into the system routing table, but not into vyatta's routing table, so my bgp routes still don't work, and creating any static routes doesnt work from within vyatta. I'm going to try recreating the bgp routes from the command line and see if I can at least get the traffic flowing. -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Nov 30, 2007, at 2:20 PM, Robyn Orosz wrote: Hi Aubrey, I cannot get any of the pppd 'netmask' parameters to take effect. We'll definitely look into that. In the mean time, can you try adding a route instead of changing the netmask via ifconfig: route add -net 64.211.X.32 netmask 255.255.255.252 wan0.1 We have recursive routing enabled in VC3 and that's why the next-hops for your routes are being translated to the default route next-hop. The eBGP next-hop is considered recursive because it's a host route (not directly connected). Without the recursive routing enabled, I'm pretty sure your BGP session would not even come up which is what is indicated in comment #2 in bug 2332. Also, since recursive routing is enabled, if I add a similar route (above) via the CLI, it adds it in as a static recursive route so instead translates the next-hop to the default route value. Anyway, let me know if just adding the route via the bash shell does any good. Thanks again, Robyn Robyn Orosz wrote: This worked for me here but I have control over the other side (it's just another Vyatta with another Sangoma card in it). I am assuming the other side of your connection is a provider of some sort? I'll see if there is another way to do this without disrupting your connection. Aubrey Wells wrote: I have to partially take that back. When I did the manual ip change, it took the wan0.1 vif down and it didn't come back up. That's why I lost the other side. -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Nov
Re: [Vyatta-users] bgp not using advertised next-hop
Hi Aubrey,
I cannot get any of the pppd 'netmask' parameters to take effect. We'll
definitely look into that. In the mean time, can you try adding a route
instead of changing the netmask via ifconfig:
route add -net 64.211.X.32 netmask 255.255.255.252 wan0.1
We have recursive routing enabled in VC3 and that's why the next-hops
for your routes are being translated to the default route next-hop. The
eBGP next-hop is considered recursive because it's a host route (not
directly connected). Without the recursive routing enabled, I'm pretty
sure your BGP session would not even come up which is what is indicated
in comment #2 in bug 2332. Also, since recursive routing is enabled, if
I add a similar route (above) via the CLI, it adds it in as a static
recursive route so instead translates the next-hop to the default route
value.
Anyway, let me know if just adding the route via the bash shell does any
good.
Thanks again,
Robyn
Robyn Orosz wrote:
This worked for me here but I have control over the other side (it's
just another Vyatta with another Sangoma card in it). I am assuming the
other side of your connection is a provider of some sort? I'll see if
there is another way to do this without disrupting your connection.
Aubrey Wells wrote:
I have to partially take that back. When I did the manual ip change,
it took the wan0.1 vif down and it didn't come back up. That's why I
lost the other side.
--
Aubrey Wells
Senior Engineer
Shelton | Johns Technology Group
A Vyatta Ready Partner
www.sheltonjohns.com
On Nov 30, 2007, at 11:20 AM, Aubrey Wells wrote:
I'm using VC3. I tried the workaround and it didnt work. The network
is in the routing table now, but its defined as going out eth5 instead
of wan0.1 and my routes are still hosed. Also, now I can't see the
other side of the DS3 since the system is trying to source 64.211.X.
32/30 out of eth5. :-(
vyatta:~# ifconfig wan0.1 64.211.X.34 netmask 255.255.255.252
vyatta:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface
206.132.X.48 8.17.X.1 255.255.255.255 UGH 0 00
eth5
64.211.X.196 8.17.X.1 255.255.255.255 UGH 0 00
eth5
64.211.X.32 8.17.X.1 255.255.255.252 UG0 00
eth5
8.17.X.0 0.0.0.0 255.255.255.248 U 0 00
eth5
206.132.X.32 8.17.X.1 255.255.255.240 UG0 00
eth5
0.0.0.0 8.17.X.1 0.0.0.0 UG1 00
eth5
vyatta:~#
--
Aubrey Wells
Senior Engineer
Shelton | Johns Technology Group
404.478.2790
Support: [EMAIL PROTECTED]
www.sheltonjohns.com
On Nov 30, 2007, at 11:10 AM, Robyn Orosz wrote:
Hi Aubrey,
Are you using VC3 or supported beta? I'm pretty sure the problem is
that:
64.211.X.33 0.0.0.0 255.255.255.255 UH0 0
0 wan0.1
Is being added as a host route. This is happening because we're now
using pppd for PPP and MLPPP connections and pppd adds the remote peer
as a /32 to the routing table. There's an open bug on this:
https://bugzilla.vyatta.com/show_bug.cgi?id=2332
I'm still trying to figure out if there is a way to make pppd add a /
30
route rather than a /32. Try this workaround and let me know if it
works for you:
ifconfig wan0.1 64.211.X.34 netmask 255.255.255.252
Thank you,
Robyn
Aubrey Wells wrote:
OFR hates me today. :-(
I have a new router with a DS3 in it running bgp over the ds3.
everything looks good except that all my bgp routes are being
inserted
into the routing table with a next-hop of the default route, instead
of the received next-hop form bgp. Any idea what's going on? I've
rebooted a few times, removed and readded the peer, etc but I'm
stumped.
Relevant info below:
## vyatta config ##
[EMAIL PROTECTED] show configuration
protocols {
bgp {
bgp-id: 64.211.X.34
local-as: 65000
peer 64.211.X.33 {
local-ip: 64.211.X.34
as: 6745
next-hop: 64.211.X.34
}
}
static {
route 0.0.0.0/0 {
next-hop: 8.17.X.1
}
}
}
policy {
}
interfaces {
loopback lo {
}
ethernet eth0 {
}
ethernet eth1 {
}
ethernet eth2 {
}
ethernet eth3 {
}
ethernet eth4 {
}
ethernet eth5 {
address 8.17.X.2 {
prefix-length: 29
}
}
serial wan0 {
encapsulation: ppp
t3-options {
}
ppp {
vif 1 {
address {
local-address: 64.211.X.34
prefix-length: 30
remote-address: 64.211.X.33
Re: [Vyatta-users] bgp not using advertised next-hop
Hi Aubrey, Thanks for trying that and I'm sorry it still didn't resolve the issue. This problem does not exist in pre-VC3 versions. With your configuration as it is, everything should work fine in 2.2. If you need to use VC3, you can kill the pppd process and reconfigure the Sangoma driver to run PPP. I'm still looking into another way to manipulate pppd so that it will accept a netmask value but if you'd like to try the Sangoma workaround you'll need to: 1. Edit the /etc/wanpipe/wanpipe1.conf file: change: wan0.1 = wanpipe1, 0, TTY, tty, wan0.tty to wan0.1 = wanpipe1, 1, WANPIPE, ppp, wan0.ppp then change: [wan1.tty] to [wan0.ppp] PAP = NO CHAP = NO 2. Edit the /etc/wanpipe/interfaces/wan0.1 file: It should be empty so you'll need to add: DEVICE=wan0.1 IPADDR=64.211.X.34 NETMASK=255.255.255.252 POINTOPOINT=64.211.X.33 ONBOOT=yes 3. Then run a 'wanrouter restart' I tested this here and it worked for me by bringing the wan0.1 /30 route into the xorp routing table. If you do decide to use VC3 and run ppp via the Sangoma driver, all of the above will need to be scripted so it will be re-added on boot. I know this is not the best workaround but give it a try if you're up to it and I'll still see if I can come up with anything better in the mean time. Thanks, Robyn Aubrey Wells wrote: Adding it from the shell gets the /30 into the system routing table, but not into vyatta's routing table, so my bgp routes still don't work, and creating any static routes doesnt work from within vyatta. I'm going to try recreating the bgp routes from the command line and see if I can at least get the traffic flowing. -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Nov 30, 2007, at 2:20 PM, Robyn Orosz wrote: Hi Aubrey, I cannot get any of the pppd 'netmask' parameters to take effect. We'll definitely look into that. In the mean time, can you try adding a route instead of changing the netmask via ifconfig: route add -net 64.211.X.32 netmask 255.255.255.252 wan0.1 We have recursive routing enabled in VC3 and that's why the next-hops for your routes are being translated to the default route next-hop. The eBGP next-hop is considered recursive because it's a host route (not directly connected). Without the recursive routing enabled, I'm pretty sure your BGP session would not even come up which is what is indicated in comment #2 in bug 2332. Also, since recursive routing is enabled, if I add a similar route (above) via the CLI, it adds it in as a static recursive route so instead translates the next-hop to the default route value. Anyway, let me know if just adding the route via the bash shell does any good. Thanks again, Robyn Robyn Orosz wrote: This worked for me here but I have control over the other side (it's just another Vyatta with another Sangoma card in it). I am assuming the other side of your connection is a provider of some sort? I'll see if there is another way to do this without disrupting your connection. Aubrey Wells wrote: I have to partially take that back. When I did the manual ip change, it took the wan0.1 vif down and it didn't come back up. That's why I lost the other side. -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group A Vyatta Ready Partner www.sheltonjohns.com On Nov 30, 2007, at 11:20 AM, Aubrey Wells wrote: I'm using VC3. I tried the workaround and it didnt work. The network is in the routing table now, but its defined as going out eth5 instead of wan0.1 and my routes are still hosed. Also, now I can't see the other side of the DS3 since the system is trying to source 64.211.X. 32/30 out of eth5. :-( vyatta:~# ifconfig wan0.1 64.211.X.34 netmask 255.255.255.252 vyatta:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 206.132.X.48 8.17.X.1 255.255.255.255 UGH 0 00 eth5 64.211.X.196 8.17.X.1 255.255.255.255 UGH 0 00 eth5 64.211.X.32 8.17.X.1 255.255.255.252 UG0 00 eth5 8.17.X.0 0.0.0.0 255.255.255.248 U 0 00 eth5 206.132.X.32 8.17.X.1 255.255.255.240 UG0 00 eth5 0.0.0.0 8.17.X.1 0.0.0.0 UG1 00 eth5 vyatta:~# -- Aubrey Wells Senior Engineer Shelton | Johns Technology Group 404.478.2790 Support: [EMAIL PROTECTED] www.sheltonjohns.com On Nov 30, 2007, at 11:10 AM, Robyn Orosz wrote: Hi Aubrey, Are you using VC3 or supported beta? I'm pretty sure the problem is that: 64.211.X.33 0.0.0.0 255.255.255.255 UH0 0 0 wan0.1 Is being added as a host route. This is happening because we're now using pppd for PPP and MLPPP
Re: [Vyatta-users] bidirectional NAT and firewall rules.
Hi Rob,
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.
Thanks,
Robyn
Rob Shepherd wrote:
An-Cheng Huang wrote:
Hi Rob,
Each firewall rule set has an implicit default drop rule at the end.
As a result, for the public_port_forwarding rule set, any packets not
matching rules 10 and 20 (i.e., non-PPTP packets) are dropped by the
default drop rule. So the problem is probably that the returning packets
of the SNATed outgoing connections are also dropped this way.
You might want to try adding something like the following to the rule
set to allow the returning SNATed traffic.
rule 30 {
protocol: tcp
state {
established: enable
new: disable
related: enable
invalid: disable
}
action: accept
}
You can also add more restrictions to match the SNAT rules, for example.
Thank you An-Cheng.
The documentation is weak for the state keywords. I see now that these
keywords are for matching traffic. Thanks.
However, it will only permit me to set state attributes of a rule if it is TCP
only. What happens to UDP,ICMP,GRE traffic? I will however test out your
comments above and report back.
Thanks very much, and kindest regards
Rob
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Vyatta Stateful Firewall Issue
: 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
Re: [Vyatta-users] Vyatta Stateful Firewall Issue
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
Re: [Vyatta-users] Vyatta VPN and NAT
Hi Adrian, You can workaround this in iptables by adding jump rules in the nat table that send your VPN packets directly to the forward table. Then you can add a third rule that NATs source network 192.168.40.0/24 to every other destination. The rules are operated on in sequence so as long as the VPN NAT rules are added first, they will be sent to the forward table before they hit the last rule that's actually performing NAT. Please take a look at the following Bugzilla report that describes a similar scenario and has examples of the rules to add directly to iptables: https://bugzilla.vyatta.com/show_bug.cgi?id=2067 The Vyatta CLI simply configures iptables rules that correspond to the NAT or firewall rule you've configured. If there are things that can't be done in the CLI but can be done in iptables, you can just add them into iptables manually. Please let us know if you find things that the CLI can't do with regard to iptables that you'd like to have added. If it's not already reported in Bugzilla, you can open an enhancement request directly through Bugzilla (https://bugzilla.vyatta.com/). If you decide to add rules directly to iptables, they'll need to be scripted and the script will need to be activated after the system boots. Otherwise, the rules will disappear when you reboot your system. I hope this helps. Thank you, Robyn Adrian F. Dimcev wrote: Hi, I'm putting an article on my website about how to create a site-to-site connection between Vyatta and ISA 2006. There is a little problem with the NAT scenario when I'm NAT-ing from Internal to External. If the remote site contains multiple subnets which are not contiguos so they can be summarize, Vyatta offers just an exclusion from *all* and not a negation(like with Cisco ACLs). let me explain: local net 192.168.40.0/24. Remote 192.168.10.0/24 and 192.168.30.0/24 If I create a NAT rule like source 192.168.40.0/24 and destination !192.168.10.0/24 then this rule will NAT from 192.168.40.0/24 to 192.168.30.0/24 because !192.168.10.0/24 means all networks except 192.168.10.0/24. I found a quick compromise with two rules: source !192.168.40.0/24 and destination 192.168.10.0/24 source !192.168.40.0/24 and destination 192.168.30.0/24 This is not quite correct since it will attempt to NAT from all networks except 192.168.40.0/24 to 192.168.10.0/24 and 192.168.30.0/24. But since there are no other networks behind that Vyatta specific interface and some firewall rules will be in place it should work(actually does the trick). But once again there is a problem if behind that Vyatta interface are multiple subnets which are not contigous so they can be summarize. Now that is another problem. Are there any other ways for exclusion from NAT? Regards! ___ 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] What am I overlooking here?
Hi Mellisa, Does the edge router have a route for networks 172.16.16.0/24 and 172.16.17.0/24 pointing to the Vyatta router at 192.168.1.2 or 192.168.100.1 (I'm not clear which is or if both are assigned to eth0)? Also, what is the address of the Vyatta eth0? Is it 192.168.1.2 or 192.168.100.1? This looks a bit strange: 192.168.100.0/24[connected(0)] to 192.168.1.2via eth0 Thank you, Robyn melissad wrote: Okay, humbly I have to admit embarrassment over this problem so far less complex than the ones I read here. Am brand new to Vyatta, and it has been six years since I did any hands-on router wrangling. Application is to isolate two file servers. Static routes are required (ancient history for me). While the Vyatta router can ping everything, traffic does not transverse the Vyatta router. The Vyatta firewall is not enabled, as far as I can determine with my knowledge of the CLI. At least, I have not enabled it. Specifics are below. If anyone can tell me how to remedy this, I would be greatly appreciative, as 3 days behind schedule on this project. PROBLEM: File Servers cannot PING Edge Router : Static route hole in Vyatta Description: 1. Static Routes: [EMAIL PROTECTED]show route 0.0.0.0/0 [static(1)] to 192.168.100.1 via eth0 127.0.0.1/8 [connected(0)] to 127.0.0.1 via lo 172.16.16.0/24 [connected(0)] to 172.16.16.1via eth1 172.16.17.0/24 [connected(0)] to 172.16.17.1via eth2 192.168.100.0/24[connected(0)] to 192.168.1.2via eth0 2. From [EMAIL PROTECTED] All pings successful to edge router and to file servers on directly connected interfaces. 3. From File Server 0 AND File Server 1, can ping successfully Vyatta eth1 - 172.16.16.1 Vyatta eth2 - 172.16.17.1 Vyatta eth0 - 192.168.100.1 4. Neither File Server can ping the other OR the Edge Router 5. The Edge Router can ping the directly connected eth0 interfacs on Vyatta can NOT ping the Vyatta eth1 or eth2 interfaces hence cannot ping the file servers can ping the directly connected workstation 6. The Workstation can ping the Vyatta eth0 @ 192.168.100.1 through the Edge Router 5. Diagram: Edge Router 192.168.100.1/24_Ping OK_ || | 192.168.100.100/24 | | Workstation0 | | | ___Ping OK__|__ |__L2 Switch 0 | 192.168.1.2/24 V65 - Vyatta Router | | | | eth1 | |eth2 172.16.16.1/24172.16.17.1/24 | | Ping OK_|___|__Ping OK__ |___|___L2 Switch 1 | | | | 172.16.16.100/24 172.16.17.100/24 File Server 0 File Server 1 Any assistance would be appreciated. melissa ___ 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] Prevent root ssh login, but allow shell access?
Hi Daren, Take a look at this post from Robert which explains how to work around the /etc/passwd file getting overwritten on boot: http://mailman.vyatta.com/pipermail/vyatta-users/2007-September/001988.html It's actually in response to one of your posts. ;-) The /etc/passwd file will only be overwritten on boot not every time you make changes in the CLI so the info in the link above should work for you. As far as preventing the brute force SSH attacks on your system... You can create a firewall that only allows SSH access from specific source addresses and apply it as local on your external facing interface. You can also change the default port for ssh: [EMAIL PROTECTED] set service ssh port 2323 [edit] [EMAIL PROTECTED] commit [edit] OK Or, you can block SSH all together and delete the service from within the CLI if you don't need SSH access to your system. Thanks, Robyn Daren Tay wrote: Hi guys, I have getting alot of such entries in my log: Oct 7 14:35:12 vyatta sshd[27845]: (pam_unix) check pass; user unknown I think its just some bots trying to login. Anyway to prevent this? Also, currently I allow root login, but I don't feel safe with that option. I can disable that using DenyUser in sshd_config. Yet, I need to have access to bash, since users other than root will go straight to XORPSH. If I try to manually create a user with bash access in the system using useradd, it will get overwrite everytime I make changes to XORPSH. What's the best way about this? Daren ___ 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] 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
Re: [Vyatta-users] Main Vyatta web Page mysteriously gone and no login prompt
Hi Jeff, We've seen this issue on systems that were improperly installed with the root and config partitions pointing to the same disk partition (ex. both root and config installed on sda1). This causes a loop in the file system that can result in the web-gui falling back to the default lighttpd page. An issue was opened in Bugzilla: https://bugzilla.vyatta.com/show_bug.cgi?id=2291 That describes the problem in more details. Is it possible that your system was installed this way? Running a 'df' from the bash shell will display the Vyatta directories and the partitions they were installed on. Thank you, Robyn Jeff wrote: Mysteriously sometime between Thursday afternoon and Monday morning the vyatta main webpage is gone and I see the lighthttpd placeholder page nor is it prompting to allow the connection as it did before and i do not know why..??? Things were all there Thursday afternoon.. I have not rebotted vyatta, and vyatta seems to be running ok Anyone with any ideas? Jeff ___ 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] Main Vyatta web Page mysteriously gone and no login prompt (FileSystem Included)
Hi Jeff, It looks like your system was installed properly (root on hde1 and config on hde2). When you run: ps -ef | grep lighttpd What is the output? When the web-gui has been started properly, there should be a process referencing the following: /opt/vyatta/etc/lighttpd.conf Can you also run: ls -l /etc/rc?.d |grep http and see if there are any symlinks pointing to the default lighttpd location (/etc/init.d/lighttpd)? Thank you, Robyn Jeff wrote: Heres a snip from the df command Copy of file system snip Linux localhost 2.6.20 #1 Thu Aug 23 12:25:11 PDT 2007 i686 Welcome to Vyatta. This system is open-source software. The exact distribution terms for each module comprising the full system are described in the individual files in /usr/share/doc/*/copyright. vyatta:~# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 115339532539040 108941592 1% / udev 1024048 10192 1% /dev /dev/hde1115339532539040 108941592 1% / /dev/hde1115339532539040 108941592 1% /dev/.static/dev tmpfs 518184 0518184 0% /lib/init/rw tmpfs 518184 4518180 1% /dev/shm tmpfs 51818448518136 1% /opt/vyatta/config /dev/hde2 9085 1501 7115 18% /opt/vyatta/etc/config unionfs 51818448518136 1% /opt/vyatta/config/tmp/new_config_3608 vyatta:~# end snip *From:* Robyn Orosz [mailto:[EMAIL PROTECTED] *To:* Jeff [mailto:[EMAIL PROTECTED] *Cc:* vyatta-users@mailman.vyatta.com *Sent:* Mon, 08 Oct 2007 11:39:42 -0400 *Subject:* Re: [Vyatta-users] Main Vyatta web Page mysteriously gone and no login prompt Hi Jeff, We've seen this issue on systems that were improperly installed with the root and config partitions pointing to the same disk partition (ex. both root and config installed on sda1). This causes a loop in the file system that can result in the web-gui falling back to the default lighttpd page. An issue was opened in Bugzilla: https://bugzilla.vyatta.com/show_bug.cgi?id=2291 That describes the problem in more details. Is it possible that your system was installed this way? Running a 'df' from the bash shell will display the Vyatta directories and the partitions they were installed on. Thank you, Robyn Jeff wrote: Mysteriously sometime between Thursday afternoon and Monday morning the vyatta main webpage is gone and I see the lighthttpd placeholder page nor is it prompting to allow the connection as it did before and i do not know why..??? Things were all there Thursday afternoon.. I have not rebotted vyatta, and vyatta seems to be running ok Anyone with any ideas? Jeff ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com mailto: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] Am I right on this config
Hi Jeff, Please see my responses inline: Jeff wrote: Router Config I am going to use Vyatta with a Time Warner fiber connection I have 28 addresses assigned to us as follows (ip's changed for sake of security) on ethernet 0 (2 subnets) *set interfaces ethernet eth0 address 111.1.1.30 prefix-length 28* * * **set interfaces ethernet eth0 address 111.1.1.45 prefix-length 28** on ethernet 01 (subnet gateway to Timewarner) *set interfaces ethernet eth1 address 222.2.1.98 prefix-length 30* ** *Default Route* **set protocols static route 0.0.0.0 0.0.0.0 next-hop 222.2.1.97** ** Basically is this all I really need to route in and out, and am I correct in my assumptions? It all looks correct to me Jeff. Just make sure Time Warner is routing 111.1.1.16/28 and 111.1.1.32/28 to 222.2.1.98 and you should be good to go. Also should I declare nameservers entrys? If you declare name server entries then you'll be able to ping and trace via host name from the Vyatta router itself if you don't need to do this then just assign the name servers directly to the hosts behind eth0. I do not want to use any firewall rules, just simple routing.. If that's all you need, it looks like you're already there. I know I want ssh access in etc, but I understand that, I almost need to test this live, and am trying to make sure I am on the right path here. You can enable ssh by configuring the following: 'set service ssh' If you have a host on one of the 111.1.1.x/28 networks that are connected to eth0, you can ssh to any of the addresses assigned to the Vyatta router's interfaces. You are correct that you'll have to wait until the circuit is live before testing ssh externally. Jeff Thanks! Robyn ___ 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] Allowing FTP Connections
Hi Daren, Leave the 'exit 0' in place. Any entries into rc.local should be added before the exit 0 line. This issue is actually already fixed in our most recent releases. So, upgrading should fix it as well. If you upgrade, then there's no need to bother with rc.local. Thanks, Robyn Daren Tay wrote: Hi guys, can't remember if I replied... but thanks for the help :) there's a exit 0 in the rc.local, should I remove it prior to adding that line? Is subsequent releases fixing this problem? Thanks! Daren -Original Message- From: Robyn Orosz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 29 August 2007 22:35 To: Daren Tay Cc: Wink; vyatta-users@mailman.vyatta.com Subject: Re: [Vyatta-users] Allowing FTP Connections Hi Daren, Try doing a: Router-1:~# modprobe ip_nat_ftp Then attempt your FTP connection again and see if that works. If it does, you should add the 'modprobe ip_nat_ftp' line to the '/etc/rc.local' file so that the module will be loaded on boot. You can also run a package update to the latest version. Instructions are on this page: http://www.vyatta.com/twiki/bin/view/Community/HowToUpdate The package update is *somewhat* non-disruptive but, you will have to reboot before you can run the new version. I wouldn't say VC2 is too old but, we have been adding new features and fixing issues so rapidly that it will almost always benefit you to upgrade when a more current stable release is available. Thank you and let me know if loading the nat ftp module works for you. -Robyn Daren Tay wrote: I am using VC2. Is that too old? I can't find the ip_conntrack_ftp and the ip_nat in the system... is there any way I can add it in without upgrading it? Because we have deploy this machine router into a pre-production environment already... I did a tshark as advice, and the response is as follows. Basically my ftp client manage to do all the authentication etc... but just time out at the end. I have replace the ip address with text for security sake :) 0.00 mine ip address - server public ip address TCP 62695 21 [SYN] Seq=0 Len=0 MSS=1 460 0.000821 server public ip address - mine ip address TCP 21 62695 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 0.003708 mine ip address - server public ip address TCP 62695 21 [ACK] Seq=1 Ack=1 Win=6 5535 Len=0 0.004924 server public ip address - mine ip address FTP Response: 220 (vsFTPd 2.0.1) 0.008623 mine ip address - server public ip address FTP Request: USER st701import 0.008749 server public ip address - mine ip address TCP 21 62695 [ACK] Seq=21 Ack=19 Win =5840 Len=0 0.008780 server public ip address - mine ip address FTP Response: 331 Please specify the p assword. 0.011728 mine ip address - server public ip address FTP Request: PASS st701import 0.015016 server public ip address - mine ip address FTP Response: 230 Login successful. 0.019243 mine ip address - server public ip address FTP Request: SYST 0.019385 server public ip address - mine ip address FTP Response: 215 UNIX Type: L8 0.022724 mine ip address - server public ip address FTP Request: FEAT 0.022865 server public ip address - mine ip address FTP Response: 211-Features: 0.022869 server public ip address - mine ip address FTP Response: EPRT 0.024277 mine ip address - server public ip address TCP 62695 21 [ACK] Seq=49 Ack=119 Wi n=65417 Len=0 0.024407 server public ip address - mine ip address FTP Response: EPSV 0.044471 mine ip address - server public ip address FTP Request: PWD 0.044602 server public ip address - mine ip address FTP Response: 257 / 0.048225 mine ip address - server public ip address FTP Request: TYPE A 0.048362 server public ip address - mine ip address FTP Response: 200 Switching to ASCII m ode. 0.053214 mine ip address - server public ip address FTP Request: PORT 202,79,222,24,238,93 0.053370 server public ip address - mine ip address FTP Response: 200 PORT command success ful. Consider using PASV. 0.056698 mine ip address - server public ip address FTP Request: LIST 0.096912 server public ip address - mine ip address TCP 21 62695 [ACK] Seq=267 Ack=95 Wi n=5840 Len=0 29.923389 mine ip address - server public ip address TCP 62695 21 [FIN, ACK] Seq=95 Ack=267 Win=65269 Len=0 29.963325 server public ip address - mine ip address TCP 21 62695 [ACK] Seq=267 Ack=96 Win=5840 Len=0 35.095862 mine ip address - 202.79.220.67 FTP Request: REST 0
Re: [Vyatta-users] Vyatta config for DMZ
Hi Joe,
I'm not sure if anyone has replied to you yet so if not, here's what I
think the issue might be. Based on your configuration, it looks as if
you're NAT'ing your DMZ server. This ends up placing the DMZ server on
the same network as your LAN hosts. Normally, this would be fine if you
were running a DNS server internally which would provide your LAN hosts
with the actual address of your DMZ server - 169.254.200.8. It looks
like you're using external DNS server addresses however which are most
likely providing your LAN hosts with the outside address of your DMZ
server - 66.76.75.98.
What happens here is that the internal LAN hosts hit your NAT rule 30
which changes the destination address of their packets to
169.254.200.8. These packets will reach the server with a source
address of 169.254.200.x and a destination address of 169.254.200.8.
The server will see that the packet is coming from a host on it's own
network and will reply directly to the LAN host (bypassing the router)
with a source of 169.254.200.8 and a destination of 169.254.200.x. The
problem is that the LAN host on 169.254.200.x is expecting a return
packet from 66.76.75.98, not 169.254.200.8. So the return traffic is
not as expected and gets dropped.
One of our developers, An-Cheng, came up with a solution for this which
is described below:
Try adding the following NAT rule to your configuration:
rule 5 {
type: source
translation-type: dynamic
outbound-interface: eth+
protocols: all
source {
network: 169.254.200.0/24
}
destination {
network: 169.254.200.0/24
}
outside-address {
range {
start: 10.254.200.1
stop: 10.254.200.254
}
}
}
This NAT rule will:
1. Cause packets from your LAN hosts to the DMZ server to have a source
address of 10.254.200.x and a destination address of 169.254.200.8 when
they reach the DMZ server
2. Because these packets are not sourced from the same network as the
DMZ server, the DMZ server will send the return traffic back to the
router with a destination of 10.254.200.x and a source of 169.254.200.8
3. The router will then associate this return packet with the original
SNAT and DNAT translations and will first change the destination address
of 10.254.200.x back to the original LAN host address of 169.254.200.x
4. Next it will change the source address of the return packet from
169.254.200.8 to the public address of 66.76.75.98
This should work if this is actually the issue you are running into. If
not, let me know some more details like how you are accessing your DMZ
server from your internal LAN, etc.
Thank you,
Robyn
With the additional NAT rule
Joe Bowen wrote:
Hi,
I am trying to implement the following:
* My static IP is 208.180.116.242 gateway 208.180.116.241
* Other static ip's can be issued in the block 66.76.75.97/28
* My DMZ server is 66.76.75.98
* My private network is 169.254.200.1
Following is the config I have. It allows outside users access to my
DMZ server but I am unable to connect from a computer on the same
network. Is this setup right? What do I need to access the DMZ from a
169.254.200.xxx machine?
Thanks,
Joe Bowen
[EMAIL PROTECTED] show
protocols {
static {
route 0.0.0.0/0 {
next-hop: 208.180.116.241
}
}
}
policy {
}
interfaces {
loopback lo {
}
ethernet eth0 {
hw-id: 00:10:DC:F0:C1:42
}
ethernet eth1 {
description: SkyNetLAN
hw-id: 00:1B:21:02:60:3B
address 169.254.200.1 {
prefix-length: 24
}
}
ethernet eth2 {
description: SuddenLinkWan
hw-id: 00:1B:21:02:60:08
address 208.180.116.242 {
prefix-length: 30
}
address 66.76.75.98 {
prefix-length: 28
}
}
}
firewall {
}
service {
dhcp-server {
name SkyNetLAN {
start 169.254.200.10 {
stop: 169.254.200.240
}
network-mask: 24
dns-server 208.180.42.68
dns-server 208.180.42.100
default-router: 169.254.200.1
interface: eth1
domain-name: skynetcountrynoc.com
}
}
telnet {
}
nat {
rule 10 {
type: source
translation-type: masquerade
outbound-interface: eth2
protocols: all
source {
network: 0.0.0.0/0
}
destination {
network: 0.0.0.0/0
}
}
rule 20 {
type: destination
translation-type: static
inbound-interface: eth2
Re: [Vyatta-users] I think this is a NAT question
Hi Phenbach,
Try placing a static source NAT rule in front of your masquerade rule
that NATs address 192.168.1.13 to the outside-address 12.20.151.13.
Then also configure a destination NAT rule that NATs traffic destined to
12.20.151.13 to the inside-address 192.168.1.13.
You are also going to have to assign 192.168.1.13 to your router's
interface if the device you are connected to is expecting to get an ARP
response for that address. If the device you are connected to is
routing the 12.20.151.13/x block to your Vyatta router, then this should
just work whether you have the address assigned to an interface or not.
The rules would look similar to this (depending on what version you're
running):
rule 5 {
type: source
protocols: all
source {
address: 192.168.1.13
}
destination {
network: 0.0.0.0/0
}
outside-address {
address: 12.20.151.13
}
}
rule 10 {
type: masquerade
outbound-interface: eth0
protocols: all
source {
network: 192.168.1.0/24
}
destination {
network: 0.0.0.0/0
}
}
rule 15 {
type: destination
protocols: all
source {
network: 0.0.0.0/0
}
destination {
address: 12.20.151.13
}
inside-address {
address: 192.168.1.13
}
}
I hope this helps.
Thank you,
Robyn
FaPhenbach Phenbach wrote:
Hello!
I have my router setup to allow access to the internet using masquerade.
I have a few servers with static IP addresses.
When one of them is my mail server.
The masquerade address is 12.20.151.12
the server address is 12.20.151.13 with an inside address of 192.168.1.13
how do i set it up so the server uses the 12.20.151.13 address instead
of the 12.20.151.12 address?
I assume this would be a nat config. Are there example of the config
around?
Thanks,
Phenbach
___
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 Routing issue
Hi Jay,
It looks like you're going to have to NAT packets from your LAN in order
to reach the public networks beyond the Vyatta router. Normally, you'd
use masquerade NAT to NAT packets from your internal LAN hosts out your
external facing interface. I'm not sure if this would work properly
with your configuration however, since you have both your internal and
external networks attached to the same interface (eth0). So, you should
probably configure a source NAT rule that NATs anything sourced from
your LAN (192.168.0.0/24) to your external public address of
###.101.183.38. Depending on what version of Vyatta you're running, the
NAT rule would look similar to:
type: source
protocols: all
source {
network: 192.168.0.0/24
}
destination {
network: 0.0.0.0/0
}
outside-address {
address: ###.101.183.38
}
Also, the following portion of your configuration:
interface-route ###.100.39.56/30 {
next-hop-interface: eth0.5
next-hop-router: ###.100.39.57
}
is superfluous as ###.100.39.56/30 is available as a connected route via
interface eth0.5. So, not that it's harming anything but, you can
delete the interface route and you should still be able to reach
###.100.39.57 by way of interface eth0.5 as long as it's up and active.
Thank you,
Robyn
jay binks wrote:
I have a fairly simple ( I think ) vyatta setup...
[EMAIL PROTECTED] show
protocols {
static {
route 0.0.0.0/0 {
next-hop: ###.101.183.33
}
interface-route ###.100.39.56/30 {
next-hop-interface: eth0.5
next-hop-router: ###.100.39.57
}
}
}
interfaces {
loopback lo {
}
ethernet eth0 {
description: Internal Network
hw-id: 00:15:C5:E1:AA:9A
address 192.168.0.2 {
prefix-length: 24
}
address ###.101.183.38 {
prefix-length: 29
}
vif 5 {
description: Pipe PVX
address ###.100.39.58 {
prefix-length: 30
}
}
}
ethernet eth1 {
hw-id: 00:15:C5:E1:AA:9B
}
}
firewall {
}
service {
http {
}
ssh {
}
}
system {
ntp-server 69.59.150.135
login {
user root {
authentication {
encrypted-password: $1$$Ht7#
}
}
user vyatta {
authentication {
encrypted-password: $1$$Ht7g#
}
}
}
package {
repository community {
component: main
url: http://archive.vyatta.com/vyatta;
}
}
}
rtrmgr {
config-directory: /opt/vyatta/etc/config
}
when I log onto my vyatta box, I can ping all far end networks... no problems
and the routing appears to work correctly...
a Ping to ###.100.39.57 goes out Eth0.5 ...
and the default route takes the other network... which is great.
if I put another PC on the 192.168.0.X network.. ( say 192.168.0.10 )
and set the default route on that machine... to 192.168.0.2 ..
it sends all traffic to the vyatta box..
I Can ping 192.168.0.1 from it
I can also ping ###.101.183.38 ###.100.39.58 from this box..
( all the IP's assigned to all interfaces in vyatta )
however... I can not ping ###.100.39.57 or ###.101.183.33 ..
vyatta does not seem to be routing these packets for me..
what have I missed... ??
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Vyatta Routing issue
Hi Jay,
It looks like you're going to have to NAT packets from your LAN in order
to reach the public networks beyond the Vyatta router. Normally, you'd
use masquerade NAT to NAT packets from your internal LAN hosts out your
external facing interface. I'm not sure if this would work properly
with your configuration however, since you have both your internal and
external networks attached to the same interface (eth0). So, you should
probably configure a source NAT rule that NATs anything sourced from
your LAN (192.168.0.0/24) to your external public address of
###.101.183.38. Depending on what version of Vyatta you're running, the
NAT rule would look similar to:
type: source
protocols: all
source {
network: 192.168.0.0/24
}
destination {
network: 0.0.0.0/0
}
outside-address {
address: ###.101.183.38
}
Also, the following portion of your configuration:
interface-route ###.100.39.56/30 {
next-hop-interface: eth0.5
next-hop-router: ###.100.39.57
}
is superfluous as ###.100.39.56/30 is available as a connected route via
interface eth0.5. So, not that it's harming anything but, you can
delete the interface route and you should still be able to reach
###.100.39.57 by way of interface eth0.5 as long as it's up and active.
Thank you,
Robyn
jay binks wrote:
I have a fairly simple ( I think ) vyatta setup...
[EMAIL PROTECTED] show
protocols {
static {
route 0.0.0.0/0 {
next-hop: ###.101.183.33
}
interface-route ###.100.39.56/30 {
next-hop-interface: eth0.5
next-hop-router: ###.100.39.57
}
}
}
interfaces {
loopback lo {
}
ethernet eth0 {
description: Internal Network
hw-id: 00:15:C5:E1:AA:9A
address 192.168.0.2 {
prefix-length: 24
}
address ###.101.183.38 {
prefix-length: 29
}
vif 5 {
description: Pipe PVX
address ###.100.39.58 {
prefix-length: 30
}
}
}
ethernet eth1 {
hw-id: 00:15:C5:E1:AA:9B
}
}
firewall {
}
service {
http {
}
ssh {
}
}
system {
ntp-server 69.59.150.135
login {
user root {
authentication {
encrypted-password: $1$$Ht7#
}
}
user vyatta {
authentication {
encrypted-password: $1$$Ht7g#
}
}
}
package {
repository community {
component: main
url: http://archive.vyatta.com/vyatta;
}
}
}
rtrmgr {
config-directory: /opt/vyatta/etc/config
}
when I log onto my vyatta box, I can ping all far end networks... no problems
and the routing appears to work correctly...
a Ping to ###.100.39.57 goes out Eth0.5 ...
and the default route takes the other network... which is great.
if I put another PC on the 192.168.0.X network.. ( say 192.168.0.10 )
and set the default route on that machine... to 192.168.0.2 ..
it sends all traffic to the vyatta box..
I Can ping 192.168.0.1 from it
I can also ping ###.101.183.38 ###.100.39.58 from this box..
( all the IP's assigned to all interfaces in vyatta )
however... I can not ping ###.100.39.57 or ###.101.183.33 ..
vyatta does not seem to be routing these packets for me..
what have I missed... ??
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
