Re: again problem with alias / virtual interface

Re: again problem with alias / virtual interface

[Marco Strullato]

>Where are the RELATED,ESTABLISHED state packets ?

right, I forgot writing these lines:
-A INPUT -p udp -m udp -m state -d 82.186.92.91 --dport 53 --state NEW -j
ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j DROP

>Also, define "does not work"

Services running at a virtual interface are not availible: rules are not
applied so the firewall drop packets

>look here:

>alex@server:~$ telnet 82.186.92.91 22
>Trying 82.186.92.91...
>Connected to 82.186.92.91.
>Escape character is '^]'.
>SSH-1.99-OpenSSH_3.5p1

>same for .93
>Are you sure the services you want to connect to bind on those ips, or
0.0.0.0 ?
>Check this with netstat -tln |grep <desired port>

Now is ir running another pc at those addresses because I can't stop
services.
I have to set up a new server because now is running on a old hardware.

best regards

marco








On Mon, 19 Jul 2004 20:55:00 +0200, Batstru <batstru@email.it> wrote:
> Hi all!
> I wrote days ago: I have a problem with virutal interface and iptables:
> my pc has 2 network interface, one with a private network address and the
> other one with
> public network addresses:
> eth0 --> 192.168.1.254 / 255.255.255.0
> eth1 --> 82.186.92.90 / 255.255.255.248
> eth1:1 --> 82.186.92.91 / 255.255.255.248
> eth1:2 --> 82.186.92.92 / 255.255.255.248
> eth1:3 --> 82.186.92.93 / 255.255.255.248
> eth1:4 --> 82.186.92.93 / 255.255.255.248
> I have configured network with ifconfig and route
> iptables has this filter rules:
> *filter
> :FORWARD DROP [0:0]
> :INPUT DROP [0:0]
> :OUTPUT DROP [0:0]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m state -i eth0 --state NEW -j ACCEPT
> -A INPUT -s 192.168.1.0 -i eth0 -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 22 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 80 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport
143 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 10000
> --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 25 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport
110 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 20 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 21 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 22 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport
25 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 53 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 80 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport
110 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport
143 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport
443 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 20 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 21 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 22 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 25 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 80 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport
110 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport
143 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport
8888 --state
> NEW -j ACCEPT
> as you can see I've tried changing configuration but anything changes: it
is
> reported just a
> warning but the rule is not applied.
> -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport
25 --state
> NEW -j ACCEPT
> My pc is running Fedora core 2 and the kernel is 2.6.6 and I've just
> upgraded iptables to last
> release.
>
> The problem is that I can't access to services running at virtual
> interfaces.
> I tried to solve the problem as suggested me: I've seen that using alias
is
> deprecated so I
> tried using iproute: I set up with
> ip addr add 82.186.92.90/24 brd 82.186.92.95 dev eth1 label eth1:0
> ip addr add 82.186.92.91/24 brd 82.186.92.95 dev eth1 label eth1:1
> ip addr add 82.186.92.92/24 brd 82.186.92.95 dev eth1 label eth1:2
> ip addr add 82.186.92.93/24 brd 82.186.92.95 dev eth1 label eth1:3
> ip addr add 82.186.92.94/24 brd 82.186.92.95 dev eth1 label eth1:4
> but after service iptables restart anything changes, alias's rules doesn't
> be applied and no
> errors is reported.
> I think I'm doing something wrong with iproute but I don't know what:
shoud
> I give any command
> to enable iproute?
>
> My problem is quite strange, I've never seen such....
>
> tnks
> marco
>  --
>  Email.it, the professional e-mail, gratis per te: http://www.email.it/f
>
>  Sponsor:
>  Conto Arancio. Zero spese, stessa banca, più interessi.
>  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=657&d=20040719
>
>




 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Vuoi cambiare i tuoi interessi ma non la tua banca?
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=656&d=20-7

Re: again problem with alias / virtual interface

[Marco Strullato]

> > -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport
25 --state
> > NEW -j ACCEPT
>
> And here is the error.
>
> As me (and I believe Antony, possibly others) already told you,
> Netfilter does not know about virtual interfaces.  Virtual interfaces
> are abstractions that exist in higher levels of kernel than Netfilter
> is.  Netfilter is concerned only on which *physical* interface the
> packet is.  Replace "-i eth1:1" with "-i eth1" in above rule (and same
> for all other virtual interfaces you have) and you'll be fine:
>
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 25
> --state NEW -j ACCEPT

I've tried with just eth1 but the rule is not applied, or it seems not to be
applied

I've seen that using virtual interfaes is deprecated so I tryed to set
multilple ip with iproute.
If I set network interfaces only with iproute and not with ifconfig, network
configuration seems to be absent.
If I set network with ifconfig and not with iproute, network configuration
seems ok
So I can't to use iproute (to set interfaces) and iptables becacuse network
configuration is absent.

best regards

marco



 

 

 --

 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 

 Sponsor:

 Rinfresca la tua estate con i climatizzatori ed i ventilatori

* che trovi disponibili… Crios, Orieme, Hokkaido, Argo, Carrier, Vortice

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2650&d=20-7

again problem with alias / virtual interface

[Batstru]

Hi all!
I wrote days ago: I have a problem with virutal interface and iptables:
my pc has 2 network interface, one with a private network address and the
other one with 
public network addresses:
eth0 --> 192.168.1.254 / 255.255.255.0
eth1 --> 82.186.92.90 / 255.255.255.248
eth1:1 --> 82.186.92.91 / 255.255.255.248
eth1:2 --> 82.186.92.92 / 255.255.255.248
eth1:3 --> 82.186.92.93 / 255.255.255.248
eth1:4 --> 82.186.92.93 / 255.255.255.248
I have configured network with ifconfig and route
iptables has this filter rules:
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state -i eth0 --state NEW -j ACCEPT
-A INPUT -s 192.168.1.0 -i eth0 -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 22 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 80 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 143 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 10000
--state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 25 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 110 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 20 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 21 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 22 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport 25 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 53 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 80 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 110 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 143 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 443 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 20 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 21 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 22 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 25 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 80 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 110 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 143 --state
NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 8888 --state
NEW -j ACCEPT
as you can see I've tried changing configuration but anything changes: it is
reported just a 
warning but the rule is not applied.
-A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport 25 --state
NEW -j ACCEPT
My pc is running Fedora core 2 and the kernel is 2.6.6 and I've just
upgraded iptables to last 
release.


The problem is that I can't access to services running at virtual
interfaces. 
I tried to solve the problem as suggested me: I've seen that using alias is
deprecated so I 
tried using iproute: I set up with 
ip addr add 82.186.92.90/24 brd 82.186.92.95 dev eth1 label eth1:0
ip addr add 82.186.92.91/24 brd 82.186.92.95 dev eth1 label eth1:1
ip addr add 82.186.92.92/24 brd 82.186.92.95 dev eth1 label eth1:2
ip addr add 82.186.92.93/24 brd 82.186.92.95 dev eth1 label eth1:3
ip addr add 82.186.92.94/24 brd 82.186.92.95 dev eth1 label eth1:4
but after service iptables restart anything changes, alias's rules doesn't
be applied and no 
errors is reported. 
I think I'm doing something wrong with iproute but I don't know what: shoud
I give any command 
to enable iproute?

My problem is quite strange, I've never seen such....


tnks 
marco 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Conto Arancio. Zero spese, stessa banca, più interessi.
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=657&d=20040719

Re: again problem with alias / virtual interface

[George Alexandru Dragoi]

Where are the RELATED,ESTABLISHED state packets ?
Also, define "does not work"
look here:

alex@server:~$ telnet 82.186.92.91 22
Trying 82.186.92.91...
Connected to 82.186.92.91.
Escape character is '^]'.
SSH-1.99-OpenSSH_3.5p1

same for .93
Are you sure the services you want to connect to bind on those ips, or 0.0.0.0 ?
Check this with netstat -tln |grep <desired port>

Best regards

On Mon, 19 Jul 2004 20:55:00 +0200, Batstru <batstru@email.it> wrote:
> Hi all!
> I wrote days ago: I have a problem with virutal interface and iptables:
> my pc has 2 network interface, one with a private network address and the
> other one with
> public network addresses:
> eth0 --> 192.168.1.254 / 255.255.255.0
> eth1 --> 82.186.92.90 / 255.255.255.248
> eth1:1 --> 82.186.92.91 / 255.255.255.248
> eth1:2 --> 82.186.92.92 / 255.255.255.248
> eth1:3 --> 82.186.92.93 / 255.255.255.248
> eth1:4 --> 82.186.92.93 / 255.255.255.248
> I have configured network with ifconfig and route
> iptables has this filter rules:
> *filter
> :FORWARD DROP [0:0]
> :INPUT DROP [0:0]
> :OUTPUT DROP [0:0]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m state -i eth0 --state NEW -j ACCEPT
> -A INPUT -s 192.168.1.0 -i eth0 -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 22 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 80 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 143 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 10000
> --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 25 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 --dport 110 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 20 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 21 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 22 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport 25 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 53 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 80 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 110 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 143 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 443 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 20 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 21 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 22 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 25 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 80 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 110 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 143 --state
> NEW -j ACCEPT
> -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.93 --dport 8888 --state
> NEW -j ACCEPT
> as you can see I've tried changing configuration but anything changes: it is
> reported just a
> warning but the rule is not applied.
> -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport 25 --state
> NEW -j ACCEPT
> My pc is running Fedora core 2 and the kernel is 2.6.6 and I've just
> upgraded iptables to last
> release.
> 
> The problem is that I can't access to services running at virtual
> interfaces.
> I tried to solve the problem as suggested me: I've seen that using alias is
> deprecated so I
> tried using iproute: I set up with
> ip addr add 82.186.92.90/24 brd 82.186.92.95 dev eth1 label eth1:0
> ip addr add 82.186.92.91/24 brd 82.186.92.95 dev eth1 label eth1:1
> ip addr add 82.186.92.92/24 brd 82.186.92.95 dev eth1 label eth1:2
> ip addr add 82.186.92.93/24 brd 82.186.92.95 dev eth1 label eth1:3
> ip addr add 82.186.92.94/24 brd 82.186.92.95 dev eth1 label eth1:4
> but after service iptables restart anything changes, alias's rules doesn't
> be applied and no
> errors is reported.
> I think I'm doing something wrong with iproute but I don't know what: shoud
> I give any command
> to enable iproute?
> 
> My problem is quite strange, I've never seen such....
> 
> tnks
> marco
>  --
>  Email.it, the professional e-mail, gratis per te: http://www.email.it/f
> 
>  Sponsor:
>  Conto Arancio. Zero spese, stessa banca, più interessi.
>  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=657&d=20040719
> 
>

Re: again problem with alias / virtual interface

[Antony Stone]

On Monday 19 July 2004 7:55 pm, Batstru wrote:

> Hi all!
> I wrote days ago: I have a problem with virutal interface and iptables:
> my pc has 2 network interface, one with a private network address and the
> other one with
> public network addresses:
> eth0 --> 192.168.1.254 / 255.255.255.0
> eth1 --> 82.186.92.90 / 255.255.255.248
> eth1:1 --> 82.186.92.91 / 255.255.255.248
> eth1:2 --> 82.186.92.92 / 255.255.255.248
> eth1:3 --> 82.186.92.93 / 255.255.255.248
> eth1:4 --> 82.186.92.93 / 255.255.255.248

Same address twice??

> -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport 25
> --state NEW -j ACCEPT

You can't use ":" in netfilter interface names.   Simply use "eth1" like all 
your other rules.

I suggest you test these additional addresses with something like this:

iptables -A INPUT -p icmp -i eth1 -d 82.186.92.90 -j ACCEPT
iptables -A INPUT -p icmp -i eth1 -d 82.186.92.93 -j ACCEPT
iptables -A INPUT -p icmp -i eth1 -j ACCEPT

Then ping 82.186.92.90 from a machine connected to eth1; then ping 
82.186.92.93 from a machine connected to eth1; then use "iptables -L INPUT 
-nvx" to check the packet / byte counts for the above three rules.

You should get non-zero packet counts for the first two rules; hopefully zero 
packets for the third rule.

Also check from a machine directly connected on eth1 that you get the same MAC 
address for both the above addresses in response to an "arp -an".

Regards,

Antony.

-- 
There are only 10 types of people in the world:
those who understand binary notation,
and those who don't.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: again problem with alias / virtual interface

[Aleksandar Milivojevic]

Batstru wrote:
> Hi all!
> I wrote days ago: I have a problem with virutal interface and iptables:
> my pc has 2 network interface, one with a private network address and the
> other one with 

[snip]

> -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport 25 --state
> NEW -j ACCEPT

And here is the error.

As me (and I believe Antony, possibly others) already told you, 
Netfilter does not know about virtual interfaces.  Virtual interfaces 
are abstractions that exist in higher levels of kernel than Netfilter 
is.  Netfilter is concerned only on which *physical* interface the 
packet is.  Replace "-i eth1:1" with "-i eth1" in above rule (and same 
for all other virtual interfaces you have) and you'll be fine:

-A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 25 
--state NEW -j ACCEPT

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: again problem with alias / virtual interface

[Jamie Pratt]

Batstru wrote:
> Hi all!
> I wrote days ago: I have a problem with virutal interface and iptables:
> my pc has 2 network interface, one with a private network address and the
> other one with 
> public network addresses:
> eth0 --> 192.168.1.254 / 255.255.255.0
> eth1 --> 82.186.92.90 / 255.255.255.248
> eth1:1 --> 82.186.92.91 / 255.255.255.248
> eth1:2 --> 82.186.92.92 / 255.255.255.248
> eth1:3 --> 82.186.92.93 / 255.255.255.248
> eth1:4 --> 82.186.92.93 / 255.255.255.248

> 
> The problem is that I can't access to services running at virtual
> interfaces. 
> I tried to solve the problem as suggested me: I've seen that using alias is
> deprecated so I 
> tried using iproute: I set up with 
> ip addr add 82.186.92.90/24 brd 82.186.92.95 dev eth1 label eth1:0
> ip addr add 82.186.92.91/24 brd 82.186.92.95 dev eth1 label eth1:1
> ip addr add 82.186.92.92/24 brd 82.186.92.95 dev eth1 label eth1:2
> ip addr add 82.186.92.93/24 brd 82.186.92.95 dev eth1 label eth1:3
> ip addr add 82.186.92.94/24 brd 82.186.92.95 dev eth1 label eth1:4
> but after service iptables restart anything changes, alias's rules doesn't
> be applied and no 
> errors is reported. 
> I think I'm doing something wrong with iproute but I don't know what: shoud
> I give any command 
> to enable iproute?
> 


well, for starters, a /24 network of your ip addressing should have a 
broadcast address of 82.186.92.255 - if your broadcast ip you have there 
*is* your broadcast address (.95), your network is diced up a bit more.. 
if you know the size of your ip address space, this may help?

http://www.dnsstuff.com/tools/cidr.ch?ip=82.186.92.91

maybe this too:

http://www.cotse.com/networkcalculator.html

regards,
jamie

Re: again problem with alias / virtual interface

[Antony Stone]

On Monday 19 July 2004 8:46 pm, Jamie Pratt wrote:

> Batstru wrote:
> >
> > eth1 --> 82.186.92.90 / 255.255.255.248
> >
> > ip addr add 82.186.92.90/24 brd 82.186.92.95 dev eth1 label eth1:0
>
> well, for starters, a /24 network of your ip addressing should have a
> broadcast address of 82.186.92.255 - if your broadcast ip you have there
> *is* your broadcast address (.95), your network is diced up a bit more..
> if you know the size of your ip address space, this may help?

I would suggest /29, based on the netmask 255.255.255.248 given above.

Regards,

Antony.

-- 
People who use Microsoft software should be certified.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: again problem with alias / virtual interface

[Antony Stone]

On Monday 19 July 2004 5:30 pm, Marco Strullato wrote:

> I've tried with just eth1 but the rule is not applied, or it seems not to
> be applied

Do you mean "it does not show up when I list the rules afterwards", or do you 
mean "the rule gets entered in the list, but it does not do what I want"?

> I've seen that using virtual interfaes is deprecated so I tryed to set
> multilple ip with iproute.
> If I set network interfaces only with iproute and not with ifconfig,
> network configuration seems to be absent.

What makes you say this?   If you try adding the extra addresses with "ip addr 
add a.b.c.d dev eth0" etc, what do you get afterwards when you try "ip addr 
show"?

> If I set network with ifconfig and not with iproute, network configuration
> seems ok

We are not saying there is anything wrong as such, or won't work, with using 
ifconfig - you just aren't allowed to use the ":" in the interface name in 
the netfilter rules.

> So I can't to use iproute (to set interfaces) and iptables becacuse network
> configuration is absent.

How are you checking this?

Also, did you try the following?

On Monday 19 July 2004 8:14 pm, Antony Stone wrote:

> I suggest you test these additional addresses with something like this:
>
> iptables -A INPUT -p icmp -i eth1 -d 82.186.92.90 -j ACCEPT
> iptables -A INPUT -p icmp -i eth1 -d 82.186.92.93 -j ACCEPT
> iptables -A INPUT -p icmp -i eth1 -j ACCEPT
>
> Then ping 82.186.92.90 from a machine connected to eth1; then ping
> 82.186.92.93 from a machine connected to eth1; then use "iptables -L INPUT
> -nvx" to check the packet / byte counts for the above three rules.
>
> You should get non-zero packet counts for the first two rules; hopefully
> zero packets for the third rule.
>
> Also check from a machine directly connected on eth1 that you get the same
> MAC address for both the above addresses in response to an "arp -an".

Regards,

Antony.

-- 
What makes you think I know what I'm talking about?
I just have more O'Reilly books than most people.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: again problem with alias / virtual interface

[Aleksandar Milivojevic]

Marco Strullato wrote:
> I've tried with just eth1 but the rule is not applied, or it seems not to be
> applied
> 
> I've seen that using virtual interfaes is deprecated so I tryed to set
> multilple ip with iproute.
> If I set network interfaces only with iproute and not with ifconfig, network
> configuration seems to be absent.
> If I set network with ifconfig and not with iproute, network configuration
> seems ok
> So I can't to use iproute (to set interfaces) and iptables becacuse network
> configuration is absent.

Everything should work just fine using virtual interfaces (configured
the standard way using good old ifconfing).  I just did quick test on my
Fedora box, and virtual interfaces worked just fine with iptables rules.

Looking at your firewall rules, there are two things:

First the cosmetic one (that doesn't brake anything, but does not have
much sense):

   -A INPUT -m state -i eth0 --state NEW -j ACCEPT
   -A INPUT -s 192.168.1.0 -i eth0 -j ACCEPT

You obviously have intention to accept all incoming connection on eth0
with first rule (which doesn't do what you wanted it to do, read bellow
why).  What is the purpuse of the second rule?

Second thing, you are using "-m state --state NEW" in (almost) all of
your firewall rules.  But you don't have any rules for packets in
"ESTABLISHED" (and/or "RELATED") state.  With this config, you are
letting only the first packet to go through firewall, and you are
blocking all subsequet packets (going in or out).  If you use tcpdump to
analyze network traffic, you could see initial packet with SYN flag
going into the interface, but no response (with ACK flag) going out
(because your firewall rules blocked it).

Now you need to do either of the following (but not both):

You either need to add generic set of rules like this (for performance,
add this as close to the top of your rules as possible):

   -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
   -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
   -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Or (if you are more paranoid) to add rules for ESTABLISHED and RELATED
packets for each port you want to have open.  For example, you would
change this line that doesn't do what you intended to do:

    -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.90 \
       --dport 22 --state NEW -j ACCEPT

to this set of lines that should do what you intended to do (first line
allows first and subseqent packets to go in, second allows outgoing
packets to go out, and last two are to allow exchange of eventual ICMP
packets related to this connection, if any):

    -A INPUT -i eth1 -p tcp -d 82.186.92.90 --dport 22 \
       -m state --state NEW,ESTABLISHED
    -A OUTPUT -o eth1 -p tcp -s 82.186.92.90 --sport 22 \
       -m state --state ESTABLISHED
    -A INPUT -i eth1 -p icmp -d 82.186.92.90 -m state --state RELATED
    -A OUTPUT -o eth1 -p icmp -s 82.186.92.90 -m state --state RELATED

I've tossed the order of options around, to make things more readable to
the human (and removed not needed options).

You can even complicate this a bit more by allowing only certain types
of ICMP messages, if you feel paranoid enough (and skilled enough not to
block ICMPs that you shouldn't block).

Also, check that your network is configured properly (check netmasks and
broadcast addresses of network interfecase, check that all interfaces
are up (there must be "UP" keyword in the ifconfig output), routing
tables, and so on).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: again problem with alias / virtual interface

[Aleksandar Milivojevic]

Aleksandar Milivojevic wrote:
[snip]
>    -A INPUT -i eth1 -p tcp -d 82.186.92.90 --dport 22 \
>       -m state --state NEW,ESTABLISHED
>    -A OUTPUT -o eth1 -p tcp -s 82.186.92.90 --sport 22 \
>       -m state --state ESTABLISHED
>    -A INPUT -i eth1 -p icmp -d 82.186.92.90 -m state --state RELATED
>    -A OUTPUT -o eth1 -p icmp -s 82.186.92.90 -m state --state RELATED

I forgot "-j ACCEPT" in all of the above.  Sorry for the omission...

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: again problem with alias / virtual interface

[Batstru]

Thanks you for suggestion but I shoud have another kind of problem. I think
my problem isn't on rules but over somewhere else: as Antony Stone wrote I
tryed "iptables -L INPUT -nvx" to see if I get zero packets counts and the
answer of a telnet 82.186.92.91 25 is 
[root@maya root]# iptables -L INPUT -nvx
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- eth1 * 0.0.0.0/0 82.186.92.91 tcp dpt:25 state
NEW,ESTABLISHED
0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 82.186.92.90
0 0 ACCEPT icmp -- eth1 * 0.0.0.0/0 82.186.92.93
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
and if I ping 82.186.92.90
[root@maya root]# iptables -L INPUT -nvx
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
9 790 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 168 ACCEPT icmp -- eth1 * 0.0.0.0/0 82.186.92.90
I can see that the icmp rule 
iptables -A INPUT -p icmp -i eth1 -d 82.186.92.90 -j ACCEPT
works but the rule
-A INPUT -i eth1 -p tcp -d 82.186.92.90 --dport 22 
-m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth1 -p tcp -s 82.186.92.90 --sport 22 
-m state --state ESTABLISHED -j ACCETP
is applied but I have zero packets count.
So I tryed with tcpdump: I log into anoher pc and I telnet 82.186.92.91 25.
At local host I 
try:
[root@maya root]# tcpdump -i eth1 | grep
host91-92.pool82186.interbusiness.it
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:31:41.895811 IP bella.dei.unipd.it.52242 >
host91-92.pool82186.interbusiness.it.smtp: S 
891791967:891791967(0) win 24820 <nop,nop,sackOK,mss 1460>
11:31:45.257887 IP bella.dei.unipd.it.52242 >
host91-92.pool82186.interbusiness.it.smtp: S 
891791967:891791967(0) win 24820 <nop,nop,sackOK,mss 1460>
11:31:52.006557 IP bella.dei.unipd.it.52242 >
host91-92.pool82186.interbusiness.it.smtp: S 
891791967:891791967(0) win 24820 <nop,nop,sackOK,mss 1460>
190 packets captured
291 packets received by filter
0 packets dropped by kernel
I can see that the just the first packet arrives but anything leave my host.
I don't know why... 
So I can't understand why with telnet 82.186.92.91 25 iptables -L INPUT -nvx
detect that any 
packet is dropped and anypacket is accepted by the rule. Where packets go?
I have also seen that iproute configurtion is correct with 
ip addr show dev eth1
with the anser
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:40:f4:62:38:fd brd ff:ff:ff:ff:ff:ff
    inet 82.186.92.90/29 brd 82.186.92.95 scope global eth1
    inet 82.186.92.91/29 brd 82.186.92.95 scope global secondary eth1:1
    inet 82.186.92.92/29 brd 82.186.92.95 scope global secondary eth1:2
    inet 82.186.92.93/29 brd 82.186.92.95 scope global secondary eth1:3
    inet 82.186.92.94/29 brd 82.186.92.95 scope global secondary eth1:4

best regards
marco


--------- Original Message --------
Da: "Aleksandar Milivojevic" <amilivojevic@pbl.ca>
To: "Netfilter User Mailinglist" <netfilter@lists.netfilter.org>
Oggetto: Re: again problem with alias / virtual interface
Data: 20/07/04 21:25

Aleksandar Milivojevic wrote:
[snip]
> -A INPUT -i eth1 -p tcp -d 82.186.92.90 --dport 22 
> -m state --state NEW,ESTABLISHED
> -A OUTPUT -o eth1 -p tcp -s 82.186.92.90 --sport 22 
> -m state --state ESTABLISHED
> -A INPUT -i eth1 -p icmp -d 82.186.92.90 -m state --state RELATED
> -A OUTPUT -o eth1 -p icmp -s 82.186.92.90 -m state --state RELATED
I forgot "-j ACCEPT" in all of the above. Sorry for the omission...
-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited
Systems Administrator 1499 Buffalo Place
Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Vuoi completare i tuoi studi?
Cepu offre una soluzione di insegnamento individuale e personalizzato
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2617&d=20040721 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 18 Bottiglie di eccellenti vini Giordano + 7 specialità alimentari +
1 batteria di pentole da 10 pezzi in acciaio Tutto a metà prezzo!

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2625&d=20040721

Re: again problem with alias / virtual interface

[Marco Colombo]

On Mon, 19 Jul 2004, Marco Strullato wrote:

> > > -A INPUT -p tcp -m tcp -m state -i eth1:1 -d 82.186.92.91 --dport
> 25 --state
> > > NEW -j ACCEPT
> >
> > And here is the error.
> >
> > As me (and I believe Antony, possibly others) already told you,
> > Netfilter does not know about virtual interfaces.  Virtual interfaces
> > are abstractions that exist in higher levels of kernel than Netfilter
> > is.  Netfilter is concerned only on which *physical* interface the
> > packet is.  Replace "-i eth1:1" with "-i eth1" in above rule (and same
> > for all other virtual interfaces you have) and you'll be fine:
> >
> > -A INPUT -p tcp -m tcp -m state -i eth1 -d 82.186.92.91 --dport 25
> > --state NEW -j ACCEPT
> 
> I've tried with just eth1 but the rule is not applied, or it seems not to be
> applied
> 
> I've seen that using virtual interfaes is deprecated so I tryed to set
> multilple ip with iproute.
> If I set network interfaces only with iproute and not with ifconfig, network
> configuration seems to be absent.

You need to specify the right label when you add an address with 'ip'.
If you do that, ifconfig will be able to recognize that as a 'virtal
interface'. It works for me:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:C0:F0:4D:8A:9A  
          inet addr:10.10.10.13  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::2c0:f0ff:fe4d:8a9a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14496652 errors:1 dropped:0 overruns:0 frame:0
          TX packets:8472210 errors:163 dropped:0 overruns:0 carrier:163
          collisions:0 txqueuelen:1000 
          RX bytes:824477902 (786.2 Mb)  TX bytes:863796083 (823.7 Mb)
          Interrupt:5 Base address:0xb800 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3848129 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3848129 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2569589493 (2450.5 Mb)  TX bytes:2569589493 (2450.5 Mb)

# ip address add 10.10.222/24 dev eth0 label eth0:1

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:C0:F0:4D:8A:9A  
          inet addr:10.10.10.13  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::2c0:f0ff:fe4d:8a9a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14496734 errors:1 dropped:0 overruns:0 frame:0
          TX packets:8472273 errors:163 dropped:0 overruns:0 carrier:163
          collisions:0 txqueuelen:1000 
          RX bytes:824563441 (786.3 Mb)  TX bytes:863802272 (823.7 Mb)
          Interrupt:5 Base address:0xb800 

eth0:1    Link encap:Ethernet  HWaddr 00:C0:F0:4D:8A:9A  
          inet addr:10.10.222.0  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14496734 errors:1 dropped:0 overruns:0 frame:0
          TX packets:8472273 errors:163 dropped:0 overruns:0 carrier:163
          collisions:0 txqueuelen:1000 
          RX bytes:824563441 (786.3 Mb)  TX bytes:863802272 (823.7 Mb)
          Interrupt:5 Base address:0xb800 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3848129 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3848129 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2569589493 (2450.5 Mb)  TX bytes:2569589493 (2450.5 Mb)


But the whole idea of 'virtual interfaces' is obsolete. The linux kernel
(and thus iptables) knows only of physical interfaces and ip addresses.
You can set a label for each ip address, but that's only a trick to make
the old ifconfig work. Labels are, well, just labels, the kernel doesn't
need them at all. If you're using 'ip' to configure ip addresses, you
can forget about labels (but ifconfig won't work).

Stop using ifconfig. Stop thinking in terms of 'virtal interfaces'.
You can't do what you're trying to do because virtual interfaces don't
exist [*]. Please think in terms of physical interfaces and ip addresses.

> If I set network with ifconfig and not with iproute, network configuration
> seems ok
> So I can't to use iproute (to set interfaces) and iptables becacuse network
> configuration is absent.

To show your current configuration, type:

ip address show

that will give you the _real_ configuration. This is true anyway, even
if you use ifconfig to set it up. You may use ifconfig if you're
more confortable with it, just remember that those 'eth0:1', 'eth0:2', ...
are just _labels_, not iterfaces.
You can't filter packets coming from a label.

.TM.

[*] There are VLANs of course, which are the only real 'virtual interfaces',
and the syntax is different: eg. eth0.1. But those are a different beast.
You can forget about them if you don't play with switches that support
them and with ports in 'trunking' mode.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: again problem with alias / virtual interface

[Michael Sconzo]

On Wed, Jul 21, 2004 at 05:34:29PM +0200, Marco Colombo wrote:

> But the whole idea of 'virtual interfaces' is obsolete. The linux kernel
> (and thus iptables) knows only of physical interfaces and ip addresses.
> You can set a label for each ip address, but that's only a trick to make
> the old ifconfig work. Labels are, well, just labels, the kernel doesn't
> need them at all. If you're using 'ip' to configure ip addresses, you
> can forget about labels (but ifconfig won't work).
> 

What is the proper way to do it, tried poking around on google, maybe
I'm just looking for the wrong thing.  Or is it even a proper way to do
it?  I have a box that is using kernel bridging so I have an IP on the 
bridged interface, but would like to have it accessable via another IP 
as well.

Thoughts?

Thanks,
-=Mike


-- 
_
_ Michael J. Sconzo
_ Computing & Information Services, Texas A&M University

The New Testament offers the basis for modern computer coding theory,
in the form of an affirmation of the binary number system.
        But let your communication be Yea, yea; nay, nay: for
        whatsoever is more than these cometh of evil.
                -- Matthew 5:37

Re: again problem with alias / virtual interface

[Aleksandar Milivojevic]

Batstru wrote:
> [root@maya root]# tcpdump -i eth1 | grep
> host91-92.pool82186.interbusiness.it
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
> 11:31:41.895811 IP bella.dei.unipd.it.52242 >
> host91-92.pool82186.interbusiness.it.smtp: S 
> 891791967:891791967(0) win 24820 <nop,nop,sackOK,mss 1460>
> 11:31:45.257887 IP bella.dei.unipd.it.52242 >
> host91-92.pool82186.interbusiness.it.smtp: S 
> 891791967:891791967(0) win 24820 <nop,nop,sackOK,mss 1460>
> 11:31:52.006557 IP bella.dei.unipd.it.52242 >
> host91-92.pool82186.interbusiness.it.smtp: S 
> 891791967:891791967(0) win 24820 <nop,nop,sackOK,mss 1460>

OK, let's to a little test.  Instead of trying to make it work all at 
once, let start building rules from the beginning, and get simple stuff 
working first.  Flush all firewall rules you have, and do something 
simple as this:

# Flush all old stuff
iptables -F
iptables -X
chains=`cat /proc/net/ip_tables_names 2>/dev/null`
for i in $chains; do iptables -t $i -F; done
for i in $chains; do iptables -t $i -X; done

After doing this, do "iptables -L" and make sure that all chains in nat 
and mangle tables have default policy set to ACCEPT (it wouldn't be good 
if for example your POSTROUTING chain in nat table is set to drop 
packets by default).

# Simple config for testing
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth1 -p icmp --icmp-type ping -m state --state NEW 
-j ACCEPT
iptables -A INPUT -i eth1 -p tcp -d 82.186.92.92 --dport 25 -m state 
--state NEW -j ACCEPT

After this, iptables -L should show that all chains in filter table are 
set to DROP packets by default, and all chains in nat and mangle tables 
are set to ACCEPT packets by default.  It should also show only above 5 
rules in filter table (3 in INPUT chain, and 1 rule in OUTPUT and 
FORWARD chains), and no rules in nat and mangle tables.

Make sure that output of iptables -L matches what is described above. 
If it doesn't match, you have remains of old configuration still loaded, 
and you need to get rid of it somehow.  You may also use iptables-save 
and check that its output matches exactly the commands you typed above, 
and that only chains in filter table have default policy set to DROP.

 From another machine, try to ping 82.186.92.92 and to ssh into it.  If 
it works, you had an error somewhere in your rules.

If it doesn't work, try adding this three logging rules *after* the 
above set of rules:

iptables -A INPUT -j LOG --log-prefix="INPUT "
iptables -A OUTPUT -j LOG --log-prefix="OUTPUT "
iptables -A FORWARD -j LOG --log-prefix="FORWARD "

This should log all dropped packets (since you will be adding this rules 
at the end, just before packets are dropped).  The log will contain all 
information about the dropped packets (interface they were dropped from, 
in which chain, and all other interesting data).

Thinking of all this, another thing come to my mind.  Your network 
configuration.  If you have more than one interface connected to the 
same "wire" (say eth0 and eth1 connected to the same hub), Linux kernel 
does not need to send response packets that arrive to address configured 
on eth1 back to eth1.  It might as well just use eth0.  Been burned by 
that once (although in different context).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: again problem with alias / virtual interface

[Aleksandar Milivojevic]

Michael Sconzo wrote:
> On Wed, Jul 21, 2004 at 05:34:29PM +0200, Marco Colombo wrote:
> 
> 
>>But the whole idea of 'virtual interfaces' is obsolete. The linux kernel
>>(and thus iptables) knows only of physical interfaces and ip addresses.
>>You can set a label for each ip address, but that's only a trick to make
>>the old ifconfig work. Labels are, well, just labels, the kernel doesn't
>>need them at all. If you're using 'ip' to configure ip addresses, you
>>can forget about labels (but ifconfig won't work).
>>
> What is the proper way to do it, tried poking around on google, maybe
> I'm just looking for the wrong thing.  Or is it even a proper way to do
> it?  I have a box that is using kernel bridging so I have an IP on the 
> bridged interface, but would like to have it accessable via another IP 
> as well.

IMHO, the proper way of doing it is using configuration files.  And let 
the init.d scripts configure your interfaces (majority of which still 
use good old ifconfig).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Re: again problem with alias / virtual interface

[Michael Sconzo]

> 
> IMHO, the proper way of doing it is using configuration files.  And let 
> the init.d scripts configure your interfaces (majority of which still 
> use good old ifconfig).

Have an example of such a config file, and what Linux distro you're using?

Thanks,
-=Mike

-- 
_
_ Michael J. Sconzo
_ Computing & Information Services, Texas A&M University

The New Testament offers the basis for modern computer coding theory,
in the form of an affirmation of the binary number system.
        But let your communication be Yea, yea; nay, nay: for
        whatsoever is more than these cometh of evil.
                -- Matthew 5:37

Re: again problem with alias / virtual interface

[Marco Colombo]

On Wed, 21 Jul 2004, Aleksandar Milivojevic wrote:

> Michael Sconzo wrote:
> > On Wed, Jul 21, 2004 at 05:34:29PM +0200, Marco Colombo wrote:
> > 
> > 
> >>But the whole idea of 'virtual interfaces' is obsolete. The linux kernel
> >>(and thus iptables) knows only of physical interfaces and ip addresses.
> >>You can set a label for each ip address, but that's only a trick to make
> >>the old ifconfig work. Labels are, well, just labels, the kernel doesn't
> >>need them at all. If you're using 'ip' to configure ip addresses, you
> >>can forget about labels (but ifconfig won't work).
> >>
> > What is the proper way to do it, tried poking around on google, maybe
> > I'm just looking for the wrong thing.  Or is it even a proper way to do
> > it?  I have a box that is using kernel bridging so I have an IP on the 
> > bridged interface, but would like to have it accessable via another IP 
> > as well.
> 
> IMHO, the proper way of doing it is using configuration files.  And let 
> the init.d scripts configure your interfaces (majority of which still 
> use good old ifconfig).

I hope that most of them have been upgraded. On Fedora Core 2:

# egrep '\<ifconfig\>' /etc/sysconfig/network-scripts/ifup
# egrep '\<ip\>' /etc/sysconfig/network-scripts/ifup 
        # Link on Physical device needs to be up but no ip required
            ip -o link set dev ${PHYSDEV} up
        curdev=`ip -o link | awk -F ':' -vIGNORECASE=1 '/$HWADDR/ { print $2 }'`
      /sbin/ip link set dev ${DEVICE} down 2>/dev/null
      /sbin/ip addr flush dev ${DEVICE} 2>/dev/null
      /sbin/ip link set dev ${DEVICE} up
    /sbin/ip link set dev ${DEVICE} down
    /sbin/ip link set dev ${DEVICE} up
   ip link set dev ${DEVICE} address ${MACADDR}
   ip link set dev ${DEVICE} mtu ${MTU}
        ip link set dev ${DEVICE} down >/dev/null 2>&1
    NUMDEFROUTES=`ip -o route | \
        ip route del default dev ${DEVICE}
         ip link set dev ${REALDEVICE} up
        ip link set dev ${REALDEVICE} $(toggle_value arp $ARP)
    if ! ip link set dev ${REALDEVICE} up ; then
    if ! LC_ALL=C ip addr ls ${REALDEVICE} | LC_ALL=C grep -q "${IPADDR}/${PREFIX}" ; then
         if ! ip addr add ${IPADDR}/${PREFIX} \
        ip route replace ${NETWORK}/${PREFIX} ${SRC} ${WINDOW:+window $WINDOW} dev ${REALDEVICE}
            ip route replace default via ${GATEWAY} ${WINDOW:+window $WINDOW} ${SRC}
            ip route replace default ${SRC} ${WINDOW:+window $WINDOW} dev ${REALDEVICE}
    ip route replace 169.254.0.0/16 dev ${REALDEVICE} 


FC2 supports the ethX:Y model via /etc/sysconfig/network-scripts/ifup-aliases,
which does use ifconfig (but as I showed before, that can be done with
ip, too). The whole point about ip/ifconfig is that the kernel uses the
ip model (the other way around, of course, ip uses the kernel model).
You MAY use ifconfig, if you know what you're doing.

I agree there's no reason to stop using ifconfig, but you should definitely
learn how the kernel works.


Michael, there no 'proper' way. If you have a 'simple' configuration,
have the standard scripts handle it, and even use the standard tools
to manipulate it (GUI or CLI). For anything more complex, you may
need to customize them by hand (with a text editor). If you're doing
something unusual, you can write your own init script. As you see,
there's no proper way.

On FC2, you use the system-config-network utility (available both in
GUI and TUI versions), for anything standard. It will create small
files like this one:
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# DEC|DECchip 21142/43
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:C0:F0:4D:8A:9A
ONBOOT=yes
TYPE=Ethernet

Now, this interface gets its address via DHCP, but you can write:
BOOTPROTO=static	# or 'none'
IPADDR=10.10.10.1
NETMASK=255.255.255.0

For custom setup, the standard scripts invoke /sbin/ifup-local if 
it exists. That way you can customize the configuration for your
needs.

Finally, nothing prevents you from rewriting /etc/rc.d/init.d/network,
which is the main init script that drives all the network configuration.
Some BSD folks would do that anytime, and I agree that one single
script with 10 or so commands it's much more readable that tens of 
scripts invoking each other and reading tens of config files here and
there. B-) For 'weird' setups I'd do that anytime, but of course
you need do know well what you're doing. The following is a standard
setup with one network card in a recent (2.6.x) Linux kernel:

# ip address show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
4: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:c0:f0:4d:8a:9a brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.13/24 brd 10.10.10.255 scope global eth0
    inet6 fe80::2c0:f0ff:fe4d:8a9a/64 scope link 
       valid_lft forever preferred_lft forever

# ip route show
10.10.10.0/24 dev eth0  proto kernel  scope link  src 10.10.10.13 
169.254.0.0/16 dev eth0  scope link 
127.0.0.0/8 dev lo  scope link 
default via 10.10.10.254 dev eth0 


If you're to write your own script, you have to get it right or something
won't work.

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: again problem with alias / virtual interface

[Michael Sconzo]

Ahh, thanks!  That clears it up.  I'll probably hack together my own
script, but that shouldn't be a big deal.  Just managed to horribly
confuse myself on the ip vs. ifconfig.

Thanks for the clarification.
-=Mike


> If you're to write your own script, you have to get it right or something
> won't work.
> 
> .TM.

-- 
_
_ Michael J. Sconzo
_ Computing & Information Services, Texas A&M University

The New Testament offers the basis for modern computer coding theory,
in the form of an affirmation of the binary number system.
        But let your communication be Yea, yea; nay, nay: for
        whatsoever is more than these cometh of evil.
                -- Matthew 5:37

Re: again problem with alias / virtual interface

[Aleksandar Milivojevic]

Michael Sconzo wrote:
>>IMHO, the proper way of doing it is using configuration files.  And let 
>>the init.d scripts configure your interfaces (majority of which still 
>>use good old ifconfig).
> 
> 
> Have an example of such a config file, and what Linux distro you're using?

Files in /etc/sysconfig/network-scripts (well, at least on Red Hatish 
systems).  Unless you have something really special that can't be done 
using standard configuration files, of course (I'm not implying that 
everything can be fitted into standard config files).  Never done 
bridges, but by looking into ifup script, there's support for it. 
Search for if [ "${TYPE}" = "Bridge" ] line.

Anyhow, the point I was trying to make wasn't about should one use 
ifconfig or ip exclusivly.  The point was that one shouldn't worry about 
whether ifconfig or ip was used to configure interfaces, if his 
configuration can be described by use of standard set of config files. 
And even if it can't be described by use of standard set of config 
files, one shouldn't choose one over another because one is being 
labeled as "obsolite" and the other is "shiny new toy".

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7