This morning's results.

Remember, this is a real-world network, not a lab situation.

(So fun to watch…)


Look a this one,

Following my actual setup and the basic setup you want to achieve (lan gaming), it should work fine.

Be aware of well understanding subnets and what "using a different subnet" for mobile clients means"

If you'r using the default 192.168.0.1 configuration and the subnet mask is 255.255.255.0, using 192.168.4.1 IS NOT A VALID DIFFERENT SUBNET.

you can have a look at my actual personnal config in this post:  https://forum.pfsense.org/index.php?topic=83781.0

my second post show print screens of a "partially working" config (you will understand if you read it all).

Zikmen

I think we would need some more explanation about that

But all routed subnet on the Pfsense LAN can be join on he remote peer (ASA)

Since a sentence cannot begin with "but" and also if the pfsense lan "can" be joinED, where is the problem exactly?

Can we have more details about your diagnosis step by step.

Zikmen

Hello Snort,

I had to pass through the trail you'r actually walking only two weeks ago.

you can find my actual and working configuration on my second reply on this post.

https://forum.pfsense.org/index.php?topic=83781.0

Give me some news about it.

Zikmen

So, since everybody had a look at my post but nobody awnsered, i did my homework myself.

I changed some settings around my subnet (now, i understand how subnetting works) and i can connect mobile devices to the vpn through the shrewsoft vpn client.

Each mobile client can ping workstations located on the main site and each workstation can also ping back and browse mobile computers.

BUT  mobile clients cannot browse or ping each others.

Mobile client 1 cannot ping mobile client 2.

Also, when using the PfSense ping utility located in the diagnostic tab, Pfsense cannot ping mobile clients.

Maby there is something that need to be adjusted in routing or nating to connect the "mobile client subnet" with the subnet where workstations and pfsense belongs to.

Some more pictures attached to explain the problem. if someone can help.

Thanks.

Tommy

1.PNG
1.PNG_thumb
2.PNG
2.PNG_thumb
3.PNG
3.PNG_thumb
4.PNG
4.PNG_thumb
5.PNG
5.PNG_thumb
6.PNG
6.PNG_thumb
7.PNG
7.PNG_thumb
8.PNG
8.PNG_thumb
9.PNG
9.PNG_thumb
10.PNG
10.PNG_thumb
11.PNG
11.PNG_thumb
12.PNG
12.PNG_thumb
13.PNG
13.PNG_thumb

Seems to be a bug in the NetGate Theme.  I just noticed that all other themes show my tunnel up in the IPSec Status page as expected, but the NetGate Theme shows a blank status.

@miken32: Try using 0.0.0.0/0 in phase 2, in local network, type network. It will route everything including internal dns. To make it work with iOS 7.2.2, here's what I've done:

phase1:

Exactly your config but using Mutual rsa+xauth.

My/peer identifier: ASN.1

My cert: create a certificate for the user you want

My cert auth: Create a cert authority in pfsense.

everything else just like yours.

Don't forget to put certificate in user.

If you need more details, just ask.

Hi again.

I basically found the solution myself: https://doc.pfsense.org/index.php/Why_can't_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN

Sometimes its hard to get the search-criteria right.

Cheers.

Perfect.

Looks like "Diff" should be the inverse of "Rekey Left".

Thanks!

Okay.  Figured this one out.  When I access my local F/W, I can just type in the host name (without the http(s):// part) and it automatically redirects to https://.  However, when I type the host name of the F/W on the other site, it does not redirect, so it's trying to hit http://host.name.com.  As soon as I type the whole thing (i.e. https://host.name.com) it works.  Not sure why I'm getting the redirect going from site B to site A and not from site A to site B, but I can live with it.

To add to Jimp's thought: You may also need to allow ping traffic on your firewall. Under Firewall, Rules, IPSec, you may need a rule that states Allow, IPSec, ICMP (echoreq), Source (Remote network), Destination (LAN Address).

Hope this helps!

felipe2k2:

It seems to me that the nature of IPSec VPN tunnels are that if Site A has traffic for Site B, the firewall at Site A is going to try to establish a tunnel with Site B to pass that traffic across.

If you are at Site B (with pfSense) and you disable the Phase 2's and Phase 1 for the tunnel to Site A (that has the Cisco ASA), no traffic will be able to pass from Site A to Site B, which is the goal.

Site A (which you have stated you do not have access to) is going to continue to try to establish a tunnel to Site B as it has traffic. As long as the tunnel config at Site B is disabled, though, you have nothing to worry about.

If the traffic from Site A is bothering you, you might consider creating a Block rule on the firewall where the source is Site A's IP address and the Destination is your WAN address. You can set the protocol to Any and block all the traffic, not just the IPSec traffic.

Hope this helps!

Thanks jimp for your reply. I will double check and try again.

SOLVED

i needed to create a static route in each firewall.

13.4.4. pfSense-initiated Traffic and IPsec
To access the remote end of IPsec connections from pfSense itself, you will need to "fake"
the system by adding a static route pointing the remote network to the system's LAN IP. Note
this example presumes the VPN is connecting the LAN interface on both sides. If your IPsec
connection is connecting an OPT interface, replace Interface and IP address of the interface
accordingly. Because of the way IPsec is tied into the FreeBSD kernel, without the static route
the traffic will follow the system's routing table, which will likely send this traffic out your WAN
interface rather than over the IPsec tunnel.

once i did that, i was able to ping from within pfsense on both sides via diagnostic, ping.  i was able to ping the remote pfsense box and get replies as well as network devices, all within pfsense.

Without knowing exactly how your IPsec Phase 1 is configured it's impossible to offer any advice. Please show your current mobile and phase 1 settings (you can redact/hide the keys of course)