Hao Wu wrote:
> 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]
