It looks confusing with so many addresses in original configuration.
Here I do a simpler configuration,
[Configuration]
Two hosts A (10.20.4.16) and B (10.20.4.15) in the same subnet, and one
tunnel is created between these two hosts.
A:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500
index 2
inet 10.20.4.16 netmask ffffff00 broadcast 10.20.4.255
ether 0:14:4f:a3:17:68
ip.tun0:
flags=11008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,ROUTER,IPv4> mtu
1480 index 4
inet tunnel src 10.20.4.16 tunnel dst 10.20.4.15
tunnel hop limit 60
inet 3.3.3.1 --> 4.4.4.1 netmask ff000000
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
4.4.4.1 3.3.3.1 UH 1 1 ip.tun0
10.20.4.0 10.20.4.16 U 1 480 bge0
224.0.0.0 10.20.4.16 U 1 0 bge0
default 10.20.4.1 UG 1 214
127.0.0.1 127.0.0.1 UH 4 5321 lo0
B:
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1100843<UP,BROADCAST,RUNNING,MULTICAST,ROUTER,IPv4> mtu 1500
index 2
inet 10.20.4.15 netmask ffffff00 broadcast 10.20.4.255
ether 0:14:4f:a2:e7:d4
ip.tun0:
flags=11008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,ROUTER,IPv4> mtu
1480 index 15
inet tunnel src 10.20.4.15 tunnel dst 10.20.4.16
tunnel hop limit 60
inet 4.4.4.1 --> 3.3.3.1 netmask ff000000
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
3.3.3.1 4.4.4.1 UH 1 1 ip.tun0
10.20.4.0 10.20.4.15 U 1 1181 bge0
224.0.0.0 10.20.4.15 U 1 0 bge0
default 10.20.4.1 UG 1 5405
127.0.0.1 127.0.0.1 UH 1 32 lo0
[Goal]
All the packets originating from 3.3.3.1 on Host A will get to Host B
through the IP-IP tunnel, regardless of
the destination of the IP packets.
[IPF rule]
#ipfstat -io
pass out quick on bge0 to ip.tun0:4.4.4.1 from 3.3.3.1/32 to any
empty list for ipfilter(in)
[Result]
Use traceroute to generate such traffic
# traceroute -i ip.tun0 192.168.0.15
But the packets is still sent to default gateway, not iptun0.
This is the display of ethereal:
========================================================================
========================
Frame 25 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: SunMicro_a3:17:68 (00:14:4f:a3:17:68), Dst:
Cisco_02:d7:c3 (00:1a:6d:02:d7:c3)
Internet Protocol, Src: 3.3.3.1 (3.3.3.1), Dst: 192.168.0.15
(192.168.0.15)
User Datagram Protocol, Src Port: 42413 (42413), Dst Port: traceroute
(33434)
Data (12 bytes)
========================================================================
=========================
Is there any problem with my configuration?
The Solaris release in both hosts are,
#cat /etc/release
Solaris 10 6/06 s10s_u2wos_09a SPARC
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 09 June 2006
Preinstall P/N 259-4616-02
Built 29 March 2007
Thanks,
Hao
>Paul Wernau wrote:
>>>> I rewrote this rule as the below, but it still didn't work, and
>>>> packets originated from 192.168.1.16 had never been encapsulated
via
>>>> IP-IP and tunneled to 10.20.4.108.
>>>>
>>>> # ipfstat -io
>>>> pass out quick on bge0 to ip.tun0:10.20.4.108 from 192.168.1.16/32
>>>> to
>>
>>>> any empty list for ipfilter(in)
>>>>
>>> I actually think you want something more like this (with in):
>>>
>>> pass in quick on bge0 to ip.tun0:10.20.4.108 from 192.168.1.16/32 to
>> any
>>> at least from my tests here with a one-interface host I can get the
>>> packets to go out over a simple tunnel that way.
>>>
>>
>> 192.168.1.16 is a local IP, and this packet is originated from local
>> host.
>> So I think it should be "out".
>>
>> Could you paste your configuration? I can try it here.
>>
>
>I literally had the above, with my IP addresses instead.
>
>But I think we're getting confused here. Can you please tell us about
your network configuration and what problem you are trying to solve.
>
>My tests were done with a host (192.168.1.16 in your case) originating
from outside. AFAIK, these kinds of in on interface pass to rules are
really mean to change routing for packets arriving at the system. If
you're talking about bge0 and the packet is never going in or out of
bge0 in a manner where it is going to be inspected, it's not going to
work.
>
>I think we could probably come up with a solution for you, but we need
more information? You're sitting on a system and you want packets with
source address 192.168.1.16 to be routed out the tunnel, but you want
packets with other source addresses (or something else?) be routed out
the default route and ignore the tunnel?
>
>Here's something else you can try if the packets are locally
originated.
> Since they are not arriving on bge0 (if I understand you correctly)
you don't want to mention that. You can simply do this, omitting bge0.
>
>pass out quick to ip.tun0:10.20.4.108 from 192.168.1.16/32 to any
>
>That would send packets sent *from* the system with source address
>192.168.1.16 out the tunnel.
>>>> this is my VPN configuration,
>>>>
>>> You're calling it a VPN configuration and/or IPsec tunnel, but it
>>> looks like a simple IP-in-IP tunnel to me.
>>>
>>
>> Yes, I already removed encr_algs and encr_auth_algs from this
IP-in-IP
>> tunnel configuration.
>>
>
>OK. The ipsecconf(1m) syntax is a superset of the ifconfig syntax and
allows address and protocol selectors, so if you can, you should
probably use that. It also will support proper tunnel mode, so for
interoperability, using "negotiate tunnel" is what you need to do. The
ifconfig is the analog to "negotiate transport" in the ipsecconf syntax.
>
>
>>>
>> I just want all the packets orginating from local 10.20.4.16 will go
>> through this tunnel.
>>
>
>Wait, I thought you wanted packets originating from 192.168.1.16 to go
through the tunnel? That's what the ipfilter rule is doing. The
>
> from 192.168.1.16/32 to any
>
>Is talking about the source and destination address.
>
>10.20.4.16 is the far end of your tunnel. It is not a local address.
>
>This is your ifconfig for reference:
>
># ifconfig ip.tun0
>ip.tun0: flags=10008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,IPv4> mtu
1480 index 9
> inet tunnel src 10.0.110.56 tunnel dst 10.20.4.16
> tunnel hop limit 60
> inet 192.168.0.56 --> 10.20.4.108 netmask ffffff00
>
>Can you show us ifconfig -a and netstat -rn?
>
>I'm sorry, but I don't understand what you're trying to do and what
these addresses represent. Am I correct that this box is not trying to
do routing in any way, as we had assumed?
>
>In any case, modify the rule above to use the address you care about or
add multiple rules for multiple addresses.
>
>>
>> What you mean here is "allowed". Will all the traffic go through this
>> tunnel regardless of its destination?
>
>No, this is IPsec policy. That's a routing decision, whether you do it
through regular routing or through playing ipfilter games. If you use
the older syntax, then any kind of traffic that gets out that interface
gets encrypted and forwarded the same way. The inner addresses are not
inspected. That may be okay for you, I don't really know.
>
>-Paul
>
>>>
_______________________________________________
networking-discuss mailing list
[email protected]
