On 5/26/2016 1:23 PM, Mark Wiater wrote:
On 5/26/2016 2:09 PM, Rosen Iliev wrote:
The other end has a conflict with our LAN addressing(192.168.1.0/24).
So in phase 2, we setup a Tunnel IPv4 using 193.168.1.0/24 for the
local Network. NAT/BINAT network of 192.168.85.0/24. Their remote
network is 192.168.75.0/24.
It's probably best to remove the conflict instead of perform the NAT. I
appreciate that re-addressing your network could be impractical though.
If the remote side is using 192.168.1/24 and you are using that same
space, it doesn't seem like using a sonicwall will make the situation
any better.
Where exactly are you looking with 'pfSense's packet capture tool'? Are
you looking on the ipsec tunnel or on your 192.168.1/24 interface?
Can the far end folks be more explicit about the failure mode? Perhaps
they could indicate exactly what response they get to the ICMP echo request?
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
Agree on removing the conflict, but unsure how easy that might be.
Packet capture on IPSec tunnel for any 192.168.75.x or 192.168.85.x
traffic. I only see traffic when I ping their host at 192.168.75.220
from the LAN(192.168.1.x).
I am not allowed to talk to the hands on person at the colo. I am only
allowed to talk to the Engineer at UBS. He stated the packets were
being rejected. I don't know anything further.
The engineer at UBS stated 'We have many tunnels setup this way using
SonicWall and a cookie cutter template for you to use.' Preliminary
investigation indicates double the cost of the appliance and around $400
per year security subscription costs for the sonicwall.
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold
