Re: [Vyatta-users] Impressions on Glendale
Brandon Bennett wrote: Great to hear that you are planning on providing customization to vbash. It is not a bad shell, it just seems odd to combine bash with my router configuration. I was afraid of tab-completion issues and accedental commands being ran (or overlapping) Hi Brandon, If your concern is that the Unix commands will get in the way of the Vyatta commands when you are in the shell, you can try logging in as an admin-level non-root user (e.g., the default vyatta user). The auto-completion and help text for admin-level users are limited to the Vyatta command only, so you don't need to worry about accidentally tab-completing a Unix command. Of course, an admin-level user still has the flexibility to enter a Unix command directly on the command line and run it. On the other hand, if you log in as an operator-level user, you'll see that only the Vyatta commands are available, i.e., the user can only see and run Vyatta operational commands on the command line. Therefore, operator-level users don't need to worry about accidentally running Unix commands, either. Going forward, we plan to provide more flexibility. For example, it's probably useful to have another level that can run all Vyatta commands (like admin) but cannot see/run Unix commands on the command line (like operator). Eventually, we will probably want to allow customizable levels such that, for example, you can set up a user level that can configure all routing protocols but not the VPN features. An-Cheng ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale Remote Access L2TP outside-nexthop
Hi Adrian, You're exactly right on the issues you pointed out. (1) Requiring some vpn ipsec parameters for vpn l2tp is a bit inconvenient, and, as you said, it may mislead users to think that the IKE/ESP settings in vpn ipsec will also apply to vpn l2tp (they don't). The main issue here is interoperability with site-to-site VPN. The ipsec-interfaces, nat-traversal, and nat-networks parameters from vpn ipsec (required for vpn l2tp) belong to the global IPsec configuration for Openswan, so setting them in vpn l2tp may change the site-to-site behavior as well, which may not be desirable. (2) The outside-nexthop parameter is sort of redundant. It corresponds to the leftnexthop parameter in the Openswan connection configuration. The problem here is that if leftnexthop is not set, it defaults to right, which won't work unless the client is directly connected. We could set it to %defaultroute by default, but that will require changing the global IPsec configuration, which, again, may change the site-to-site behavior. The current approach is to let the user configure it (using outside-nexthop). I'll investigate further to see if we can simplify this. Thanks for playing with the remote access VPN feature! Let us know if you find other issues. An-Cheng Adrian F. Dimcev wrote: So why do I need this outside-nexthop since I already have specified a default route through 192.168.30.1 ? Since my experience shows that there are problems with NAT devices, I've always done my first tests connected directly to the external interface of the VPN server. With pre-shared keys. Then with certificates. After I know that the VPN server is properly configured, I move along the path. In the beta docs, page 664, If the authentication mode is pre-shared secret, you must configure the secret using the vpn pptp remote-access outside-address ipv4 command (see page 697). statement does not appear to be correct, neither the command. It would be nice to do all the L2TP/IPsec configuration from the vpn l2tp node. Without using the vpn ipsec node. To make a clear distinction between site-to-site and remote access. The vpn ipsec node gives the feeling that the L2TP/IPsec IKE MM and QM settings are supposed to be editable(customize the proposals from the CLI). Bu it does not appears to be so. ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale Remote Access L2TP outside-nexthop
Hi Adrian, Yes, you are right that such a setup is not currently supported. Looks like it will require defining two different connections in Openswan configuration and also making sure the L2TP server can serve clients from both. Maybe we can look into extending the configuration syntax to allow multiple instances. An-Cheng Adrian F. Dimcev wrote: Hi An-Cheng, Thanks for your answer. One thing comes on my mind right now: Allow me to draw a simple and maybe common situation: Say Glendale has three interfaces: External, Internal and a so-called Wireless DMZ. Although it's a little bit archaic, some people prefer to secure their WLANs using VPN. Thus they create an anonymous DMZ where they place an AP. Then they VPN into the Internal network from this wireless DMZ. There might be certain situations where this would be a convenient solution(say some schools network designs). So we need to enable vpn l2tp on two interfaces: External and Wireless DMZ. The wireless clients are directly connected(%direct) while the road warriors are not. Looking at Glendale, currently it seems that this is not doable. Thanks, Adrian ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale First Impressions
Robert Bays wrote: Nick Davey wrote: - I don't mind the new CLI, however I REALLY miss the ? and the space auto completion. If there is any way we can work to getting that back I would be over the moon. I know there has been some discussion about this, but I figured I'd voice my opinion as well, as late as it is. I've talked with An-Cheng about ? help. I think we agreed that he would set it up that ? would bind to help by default, but that it could be turned on or off on a per user basis. I need to follow up with him on that. The fix is a one-line change to the default '?' binding, and I've just been waiting for a decision on this... An-Cheng ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Glendale First Impressions
An-Cheng Huang wrote: The fix is a one-line change to the default '?' binding, and I've just been waiting for a decision on this... Ok, it's in Glendale now. '?' now defaults to help (i.e., the possible-completions binding). An-Cheng ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] glendale problems my 1st view
Note also that if the '?' key is bound to auto-completion, the user can still input the '?' character using the readline escape sequence (i.e., in this case Ctrl-v ?). So basically it came down to a choice between these: (1) Keep '?' key as help. To input a '?' character, prefix it with Ctrl-v. (2) Use some other key sequence for help. A '?' character can be entered directly. At that time, (2) was deemed more acceptable than (1), so we currently have (2). An-Cheng An-Cheng Huang wrote: That was the first thing I tried when we started implementing the help system. The problem is when the user actually wants to input a '?' character, how do we rebind the '?' key back to the actual character? I also tried to rebind the key after seeing a quote (assuming '?' characters can only appear in quotes), etc., etc. In the end, this is a limitation in the readline library (which is used by bash for command line input). We _could_ change readline, I suppose, somewhere down the road. An-Cheng ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] glendale problems my 1st view
In case people don't know about this: instead of '?', a user can get the help text using either of the following two key sequences: Alt = or Alt ?. (These are the default key bindings for possible-completions in readline/bash.) An-Cheng Huang wrote: That was the first thing I tried when we started implementing the help system. The problem is when the user actually wants to input a '?' character, how do we rebind the '?' key back to the actual character? I also tried to rebind the key after seeing a quote (assuming '?' characters can only appear in quotes), etc., etc. In the end, this is a limitation in the readline library (which is used by bash for command line input). We _could_ change readline, I suppose, somewhere down the road. An-Cheng ___ 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] glendale problems my 1st view
Stig Thormodsrud wrote: #3 - I agree, please bring back my beloved ?! Its an automatic reflex to hit ? whenever I'm in a router. I end up hitting it 3 or 4 times before I realize that its echoing the char to the screen rather than activating help. Has anyone explored using ~/.inputrc to rebind the ? character to something for auto-completion? It might be possible, to do $if Bash ?: C-IC-I $endif Good call Stephen. I just tried: $if Bash ?: \C-i $endif Maybe we won't have to give up the ?. stig That was the first thing I tried when we started implementing the help system. The problem is when the user actually wants to input a '?' character, how do we rebind the '?' key back to the actual character? I also tried to rebind the key after seeing a quote (assuming '?' characters can only appear in quotes), etc., etc. In the end, this is a limitation in the readline library (which is used by bash for command line input). We _could_ change readline, I suppose, somewhere down the road. An-Cheng ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] [Fwd: Re: Starting to get really frustrated... GRRR :D]
so i just redid them all by hand. It still doesn't
work.
rule 1 {
type: destination
inbound-interface: eth0
protocols: tcp
destination {
address: 71.62.193.105
port-name http
}
inside-address {
address: 192.168.0.105
}
}
rule 2 {
type: masquerade
outbound-interface: eth0
protocols: all
source {
network: 192.168.0.0/24
}
destination {
network: 0.0.0.0/0
}
}
rule 3 {
type: masquerade
outbound-interface: eth0
protocols: all
source {
network: 192.168.1.0/24
}
destination {
network: 0.0.0.0/0
}
}
Nate
On Mon, 2008-01-28 at 21:39 -0800, An-Cheng Huang wrote:
Hi Nate,
The inside-address is the internal (private) IP address of
your Web server, which in your case is 192.168.0.105. The
destination
address should actually be the public IP address that outside
clients
will use to access your server, so usually this is the public IP
address
of your router.
An-Cheng
Nathan McBride wrote:
I went and looked at the old docs. I thought I set them up
correctly
but aparently I didn't. I'll im trying to do is to get
people
on the
internet to view the website on my comp (192.168.0.105).
The
only
difference that i noticed when I tried to commit the example
in the old
docs was that vc3 requires an 'inside-address'. Could
someone
please
help me correct this to get it working?
rule 3 {
type: destination
inbound-interface: eth0
protocols: tcp
destination {
address: 192.168.0.105
port-name http
}
inside-address {
address: 192.168.0.105 -- didn't know what to put
here
exactly...
}
}
___
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
___
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
___
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] Starting to get really frustrated... GRRR :D
Hi Nate,
The inside-address is the internal (private) IP address of your Web server,
which in your case is 192.168.0.105. The destination address should actually
be the public IP address that outside clients will use to access your server,
so usually this is the public IP address of your router.
An-Cheng
Nathan McBride wrote:
I went and looked at the old docs. I thought I set them up correctly
but aparently I didn't. I'll im trying to do is to get people on the
internet to view the website on my comp (192.168.0.105). The only
difference that i noticed when I tried to commit the example in the old
docs was that vc3 requires an 'inside-address'. Could someone please
help me correct this to get it working?
rule 3 {
type: destination
inbound-interface: eth0
protocols: tcp
destination {
address: 192.168.0.105
port-name http
}
inside-address {
address: 192.168.0.105 -- didn't know what to put here
exactly...
}
}
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] NAT problem
Hi Alexc,
In your source NAT rules, you should set the source address *instead of* the
inside-address. For example, for rule 10, you should do set service nat rule
10 source address 10.10.1.1 instead of setting the inside-address. Let me
know if this does what you want. Thanks!
An-Cheng
Alexc wrote:
Hi,
Sounds like vyatta vc3 has a problem with NAT, I want to map not routed
IPs to real ones with static one-to-one NAT, I did according to manual
butr all packets go out with single IP.
Please look at config and iptables output below, did I make any error
in configuration?
service {
nat {
rule 10 {
type: source
inbound-interface: vif30
outbound-interface: eth1
inside-address {
address: 10.10.1.1
}
outside-address {
address: 194.90.41.4
}
}
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Basic Rip help and nat translation question
Hi Aaron, For NAT translations, there is an enhancement request for a show command that displays the information you want. You can see some more details in bugzilla: https://bugzilla.vyatta.com/show_bug.cgi?id=522 An-Cheng [EMAIL PROTECTED] wrote: In addition, on a standard cisco router I can run this: show ip nat trans . How do I see all the differnent translations on a vyatta box going out to the world? Thanks in advance, Aaron ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Error: 102 Command failed TCP/UDP Protocol must be specified
Hi Alain,
The reason that TCP/UDP is required for your rule 35 is that you specified
port in that rule, which is only meaningful for TCP/UDP in this context. The
SNAT rule 39 accepts protocols all because it doesn't have port. Hope this
helps.
An-Cheng
Alain Kelder wrote:
Hello,
I'm trying to set protocols to all for a destination NAT rule. But Vyatta
complains that it wants either TCP or UDP. However, in this awesome how-to,
they did just that:
http://www.openmaniak.com/vyatta_case6.php#ancre-configurations
Here's what I tried:
[EMAIL PROTECTED] edit service nat rule 35
[edit service/nat/rule/35]
[EMAIL PROTECTED] set protocols all
[edit service/nat/rule/35]
[EMAIL PROTECTED] commit
[edit service/nat/rule/35]
Commit Failed
102 Command failed TCP/UDP Protocol must be specified
What's weird is that 'tab' (auto complete) shows all as an option:
[EMAIL PROTECTED] set protocols
`protocols' is ambiguous.
Possible completions:
[Enter]Execute this command
all Perform NAT on all protocol traffic
icmp Perform NAT on ICMP traffic only
tcp Perform NAT on TCP traffic only
udp Perform NAT on UDP traffic only
I'm able to set protocols to udp or tcp, but not all. What I'd like is
this:
rule 35 {
type: destination
translation-type: static
inbound-interface: eth0
protocols: all
source {
network: 0.0.0.0/0
}
destination {
address: 65.xx.xx.xx
port-number 53
}
inside-address {
address: 10.10.3.20
}
}
Interestingly, Vyatta accepts all for a source NAT rule:
rule 39 {
type: source
translation-type: static
outbound-interface: eth0
protocols: all
source {
address: 10.10.3.20
}
destination {
network: 0.0.0.0/0
}
outside-address {
address: 65.xx.xx.xx
}
}
Any ideas? Thanks a bunch in advance.. I'm at a loss!
[EMAIL PROTECTED] show version
Version:VC2
Built by: [EMAIL PROTECTED]
Built on: 200702080056 -- Thu Feb 8 00:56:19 UTC 2007
___
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] Can't connect to SMTP Host
If I remember correctly, this issue was discussed on this mailing list a couple months back, and the dual NAT solution was posted. You might want to try doing a search with the terms internal and DNS. An-Cheng Alex Lee wrote: I created a NAT Rule that forwards all traffic on port 25 from the external ip address of xx.xx.xx.xx to the internal ip address of 10.10.30.xxx on port 25. My problem is that all workstations on the internal network 10.10.30.X connect resolve mail.domain.com to port 25 on the external ip address. Using a external email client out side the network from a remote client works with out issues. All the clients on the internal network have to be configures to connect to the server directly by using the internal ip addresss for that server in the smtp settings on their client. Any suggestions? I saw the responses from Justin and Alain, but thought this was an interesting question. Is there not a way to NAT so that the external address gets translated into the internal address when coming from the internal network? I am sure we are doing this on our Checkpoint firewall. Isn't this called Dual NAT? Just wondering. Thanks, Alex ___ 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/NAT/Firewall rules
Hi Tony, You should be able to put the allowed ports in the destination port-number/portname fields in the DNAT rule. This way, only packets with those destination ports will be DNATed and be able to access the 10.1.1.2 server. An-Cheng Tony Cratz wrote: I have set-up my OFR to use DHCP with an internal address space of 10.1.1.0/24. My OFR will receive my 71.159.206.0/29 on the IP of 71.140.62.22. So I'm using NAT to map 71.159.206.2 to 10.1.1.2 (as a bi-directional NAT). Now I want to have some rules (firewall?) to allow only a few ports to connect to the 71.159.206.2 (10.1.1.2) system such as SMTP, SSH, FTP, HTTP and a few others. The question I have is should these rules be defined as Firewall rules or as NAT rules? ___ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
Re: [Vyatta-users] Firewall rules
Hi Tony,
The firewall configuration syntax only allows 1 source address within each
rule, so for your example you can specify 3 rules, one for each IP address you
want to block.
An-Cheng
Tony Cratz wrote:
Hello:
I'm new to Vyatta any before I start to do an install and
screw myself I would like a question answered.
In setting up a firewall rule I would like to reject all
connections from the IP addresses of (as an example)
216.239.32.10, 66.218.71.63, 192.18.99.5
Is the following possible or do I need to break the source
out them into different source sections?
rule 1 {
action reject
source {
address: 216.239.32.10
address: 66.218.71.63
address: 192.18.99.5
}
}
Tony
___
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] User and Password Management
Hi Daren, 1) There are several possibilities. First, make sure you are not logged in as 'vyatta' (can't delete a logged-in user). Secondly, even if you are not logged in as vyatta, if you have logged in as vyatta and then logged out, sometimes the system still shows vyatta as logged in (and thus deleting it will fail), so you might want to reboot the box, log in as root, and then delete vyatta. Finally, earlier versions have a problem where deleting a user fails intermittently, which has been corrected now. 2) Yes, the plaintext gets encrypted on commit, and the plaintext should be cleared. However, in some cases, the plaintext is still displayed afterwards. See the following bug: https://bugzilla.vyatta.com/show_bug.cgi?id=745 A workaround now is to manually delete the plaintext if this happens. 3) At the moment, all users created have the same access. Hope this helps. An-Cheng Daren Tay wrote: Hi guys, 1) How do i remove the default user 'vyatta'? I keep getting commit fail 2) For root password, I just change it but i realise i have to change it using the plaintext option On commit it will encrypt... is it normal? Also, after I commit, the plaintext password is still viewable in show system login why so? Lastly, how do I create users with different access rights? Or I can't? Thanks! 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] NAT issue (no translation-type)
Hi Keun,
The network setup and the source NAT rule look fine. I can think of a few
things that you might want to try.
1. After committing the source NAT rule, go to the Linux shell and do a
'iptables -t nat -L -vn' to list the NAT rules in the iptables. If the
corresponding source NAT rule is not in iptables, then it may be a problem with
the CLI.
2. While lan_host is sending packets to wan_host ('ping' should be sufficient
since the source NAT rule has protocol all), try to capture packets on each
interface on vyatta2. If the packets from lan_host to wan_host are not going
into vyatta2's eth0 and coming out of vyatta2's eth1, then it may be a network
issue.
3. While lan_host is sending packets to wan_host, look at the output of
'iptables -t nat -L -vn'. If NAT is working correctly, then the source NAT
rule's counter should go up as packets from lan_host to wan_host pass through
the router.
4. Depending on the version of the code you downloaded/built, there may be
NOTRACK rules in the raw table. Do a 'iptables -t raw -L -vn' and you should
see either no rules at all, or the rules should result in all packets being
ACCEPTed (since you enabled NAT). If packets are actually going to the
NOTRACK target, then that's probably why NAT is not functioning. (You can look
at the counters while lan_host is sending packets to determine where the
packets are going.)
Hope this helps.
An-Cheng
Keun Lee wrote:
The network setup is as follows. The WAN side has a single
host 'wan_host' for testing purpose. wan_host will be
replaced by a T1 or DSL modem.
eth1 eth0
+---+ +-+ +--+
| wan_host |-| vyatta2 |--| lan_host |
+---+ +-+ +--+
^ ^ ^
| |192.168.254.22
216.135.138.219/29 |
192.168.254.200/24
I want the packets from lan_host to wan_host masquaraded by vyatta2.
The nat rules are:
nat {
rule 1 {
type: source
outbound-interface: eth1
protocols: all
source {
network: 192.168.254.0/24
}
outside-address {
address: 216.135.138.219
}
}
rule 5 {
type: destination
inbound-interface: eth1
protocols: tcp
source {
network: 0.0.0.0/0
}
destination {
address: 216.135.138.219
port-name https
}
inside-address {
address: 192.168.254.209
}
}
more port forwarding rules follow ...
To test the NAT:
@lan_host (192.168.254.22): telnet wan_host http
@wan_host: tcpdump -i eth0
...IP 192.168.254.22.42767 216.135.138.217.www: ..
I expected that the source address 192.168.254.22 would be
translated to 216.135.138.219, but there was no translation.
Hope this helps. --Keun
___
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
