Hello,
We managed to get everyone involved in this together by the same machines to
test it. I added a further 2 external IPs to the testNAT box, which in theory
meant 3 sessions to any one VPN should work.
After some fiddling we did actually manage to get 3 sessions working. It appears
IPFilter picks the next external IP in an attempt to satisfy the srcport=500
requirement. Very nice.
Then they wanted to see if it was released quickly enough. So the last VPN
session disconnected, then reconnected.
The Sol10x86 froze completely. The only message on console was
"ifp: Unknown: cmd x data 5352".
Unfortunately, there is no way to know if this message is connected to the
crash.
Since it froze there were no /var/crash/ entries.
After the reboot, we never got even a single session working again! I can't work
out why either. We even restarted the NetScreen box incase it was hung sessions.
Various combinations of rules meant we either
A) "Connection to VPN..." would eventually just time out.
B) Connection would work, and username authentication would pop up, but no
(valid) combination of user/pass would work. (Also, the text in this dialog box
was garbage. Decryption issues?)
Eventually, the testNAT froze again, this time without message.
On the other front, the Junpier KB suggests enabling NAT-T to allow non-port 500
VPN sessions, but we found it is already enabled, which makes me wonder if the
port 500 thing is really the problem.
SunOS testNAT 5.10 Generic i86pc i386 i86pc
pfil-2.1.6
pfil-4.1.10
ipf.conf (permit all)
ipnat.conf:
map iprb0 from 192.168.0.0/16 port=500 to VPN/32 -> range EXTlow - EXThigh
map iprb0 192.168.0.0/16 -> range EXTlow - EXThigh proxy port 500 ipsec/udp
map iprb0 192.168.0.0/16 -> range EXTlow - EXThigh portmap tcp/udp auto
map iprb0 192.168.0.0/16 -> range EXTlow - EXThigh
During success, and failures, we would see rules like:
MAP 192.168.29.37 500 <- -> EXTlow 500 [VPN 500]
proxy ipsec/17 use 1 flags 0
proto 17 flags 0 bytes 856 pkts 2 data YES size 360
IPSec Proxy:
ICookie 01f401xxxxxxxxx RCookie 46d8608xxxxxxxxx (Set)
MAP 192.168.29.37 <- -> EXTlow [VPN]
But still not really working.
Since we can generally make it hang, is there anything I can do to help with
this problem?
Lund
Jorgen Lundman wrote:
Hello experts!
Installed fresh Sol10, pfil 2.1.6 and IPFilter 4.1.10 using the guide
we've all worked on. (It's close but some tweaks).
The ipsec proxy appears to work ok, however, from reading the FAQ and so
on, could I get something clarified?
Rules in question:
map iprb0 from 192.168.0.0/16 port=500 to VPNIP/32 -> EXTIP/32
map iprb0 192.168.0.0/16 -> EXTIP/32 proxy port 500 ipsec/udp
The first session comes up correctly, and works.
MAP 192.168.29.110 500 <- -> EXTIP 500 [VPNIP 500]
But the second does not:
MAP 192.168.29.115 500 <- -> EXTIP 1524 [VPNIP 500]
Now it would seem to me that I want source port 500 instead of 1524, on
the 2nd session, but a reply packet from VPNIP:500 destined to EXTIP:500
would not be unqiue enough for ipfilter to identify which mapping it is
referring to. Therefor this would never work, unless there was data
inside the packet to identify the matching rule.
If I am to understand the FAQ, I would need to add another external IP
for the second session to work (will it automatically pick it, port=500,
for me?). And in fact, work out what max sessions I would want to any
one VPN, and add that many external IPs?
Can I tell the netscreen to accept a non-port-500 VPN session?
Thanks in advance.
Lund
Jorgen Lundman wrote:
Solaris 10
Ipfilter 4.1.5 (plus patches making it 4.1.6ish).
No ipf.conf rules, standard NAT only rules:
map e1000g0 192.168.0.0/16 -> extint/32 proxy port ftp ftp/tcp
map e1000g0 192.168.0.0/16 -> extint/32 portmap tcp/udp auto
map e1000g0 192.168.0.0/16 -> extint/32
For some reason the "network team" decided that they want to VPN from
192.168/16 to a Netscreen in the other datacenter.
They find that the first session works well, but not the second etc.
My initial guess is that the first session gets port 500, and the
following do not.
Checking the FAQ, and this list, it would appear I should add:
#map extint from rfc1918/24 port=500 to vpnip/32 -> publicip/32
#map extint rfc1918/24 -> publicip/32 proxy port 500 ipsec/udp
At the top of ipnat.conf, in that other.
However, when I add these two lines, the other (non-VPN) NAT'ing
grinds to a halt. Sort of works, but like surfing through molasses.
Has there been any bug fixes with the VPN proxy code recently that
could account for the NAT'ing being affected by just adding these
rules? We haven't actually got to trying if the VPN's will work, since
it creates havoc whenever I add the rules.
(Removing rules, and ipnat -CF get it back again).
The Changelog on the ipfilter webpage only talks about v3 series.
Lund
--
Jorgen Lundman | <[EMAIL PROTECTED]>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
