VPN Mapping - Problem?!

[JRo]

Hey guys, a few time ago I posted a problem with setting up a VPN connection, using Adressmapping. I successfully solved the problem because very good support of this forum :) Thanks so far guys! Now to my problem: My local network is: 192.168.0.0 /24 which is mapped to 10.217.78.0 /24 over a VPN Tunnel. The network on the opposite is 172.20.1.0 /24. The reason why it' s mapped is because on the other side there is already another VPN incoming with 192.168.0.0 as source. From my side everything is working fine and I can ping every host from 192' s to 172' s network. Now today administrator from the opposite wanted to access on of our server' s (IP: 192.168.0.12) so he wanted to establish a connection to 10.217.78.12 because of the adress mapping, but he got no reply from this host. Now is there any mistake I maybe made? In the following I' ll post an extract of the firewall policy: SOURCE 172.20.1.0 DESTINATION VIP(10.217.78.0 -> 192.168.0.0) NAT enabled , ALLOW ALL SOURCE 192.168.0.0 DESTINATION 172.20.1.0 USE CENTRAL NAT Table, ALLOW ALL NAT TABLE: Original Adress: 192.168.0.0 Port:1-65535 Translated Adress: 10.217.78.* Port: 1-65535 Where is the problem? Is it on my site of the connection or on the opposite? If there are any questions, just feel free to ask :)

[rwpatterson]

Is the tunnel set up in route mode or policy based (encrypt)? If the former, you need a second policy allowing connections FROM the remote end. It' s a bit weird, but there are 2 policies: 1) traffic starting from the inside out 2) traffic starting from the outside in

[JRo]

Hmm Tunnel has been setted up in Interface-Mode, what are the characteristics of route or policy based mode? How can I find out?

[rwpatterson]

The ' action' . If it' s ' encrypt' , then you' re in policy mode. If interface mode, the tunnel terminates at the phase 1 interface, and the action is ' accept' .

[JRo]

Oh I see, thank you. The action is ' accept' on all policies. It isn' t enough to set it on encrypt, isn' t it?

[emnoc]

Encrypt is only used when policy mode, the same as if it was netscreen So if you define ur' er VPN as interface mode, you don' t NEED a encrypt. Just place the policies using your phase1 tunnel name, for both direction e.g src-interface " vpn-name" to " internal-lan" internal-lan to " vpn-name"

[JRo]

So this is exactly what I did so far, already shown in my first post.

SOURCE 172.20.1.0 DESTINATION VIP(10.217.78.0 -> 192.168.0.0) NAT enabled , ALLOW ALL SOURCE 192.168.0.0 DESTINATION 172.20.1.0 USE CENTRAL NAT Table, ALLOW ALL

Any other suggestions why the opposite can' t access our systems, using 10.217.78.* NAT?