Re: [pfSense] IPSec nat issue

[Steve Yates]

Jumping in midway through, 193.168.1.0/24 belongs to Universite du Luxembourg.  
If that's not you then the other end could be routing packets there.

--

Steve Yates
ITS, Inc.
-Original Message-
> On Wed, May 25, 2016 at 8:54 PM, Lyle  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.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec nat issue

[ED Fochler]

I agree.  I typically ssh in as root and tcpdump to get a more interactive view 
of the network, but packet capture should give you the same data.  You should 
be seeing traffic even if it is rejected or dropped by your firewall rules.  If 
you’re not seeing ping, it’s not showing up at your interface.  

ED.

> On 2016, May 26, at 8:44 AM, Vick Khera  wrote:
> 
> On Wed, May 25, 2016 at 8:54 PM, Lyle  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.
>> 
> 
> So if they have a conflicting 192.168.1.0/24 network on their end already,
> how the heck do they expect traffic to *your* version of that network to
> get routed to you? That is, if they type "ping 192.168.1.42" which network
> is it supposed to go to? I don't see how some Sonicwall magic could make
> that happen either.
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] USB3 to ethernet adaptor

[RB]

On Thu, May 26, 2016 at 10:42 AM, WebDawg  wrote:
> I posted this a while ago:
>
>
> http://seclists.org/fulldisclosure/2016/Jan/77
>
> http://seclists.org/fulldisclosure/2016/Mar/25

I see, but that has nothing to do with the security of the VLAN
implementation, rather of the switch as a whole.  That switch is
certainly awful, but it's no reason to impugn the viability of using
VLANs across the board.

> Also, just because a vulnerability has not been reported or discovered,
> does not mean it does not exist.

Nor does it mean we avoid using an entire technology because there
"might" be vulnerabilities in what has otherwise remained a stable and
useful paradigm for decades.

The question of VLAN jumping remains open, in my mind.  An
appropriate, well-configured switch fabric should have no problem
carrying vastly different security levels in different VLANs,
vulnerabilities in its management software notwithstanding.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] USB3 to ethernet adaptor

[RB]

On Wed, May 25, 2016 at 6:25 PM, Volker Kuhlmann
> I disagree. While it'll work, its security is nowhere near the same. It
> depends on the VLAN switch's firmware being bugfree (we all know about
> how likely that is), it adds complexity, and it mixes physically
> separate networks together on one cable. Perhaps it might be acceptable
> to merge networks of the same security level, merging LAN and WAN
> networks doesn't sound like a good idea to me.

Entertain me, it's been literally a decade since I last saw someone
imply that switch VLAN implementations were generally of dubious
nature.  Can you perhaps point me to a recent VLAN-crossing
vulnerability, or documented VLAN crosstalk?  We all know about the
old CAM table overflows, but that's been long fixed.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] enabling authenticated ntp ?

[Valerio Bellizzomi]

Is it possible to do from the web interface?

thanks


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec nat issue

[Rosen Iliev]

Hi Lyle,

Which IP they are pinging exactly?

Rosen

Lyle wrote on 5/25/2016 6:54 PM:
I am trying to install a new pfSense appliance running 2.3 Release. 
works fine until I setup a IPSec tunnel.


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.


I can ping and see the smb shares on their server at 192.168.75.220 
from a workstation on the 192.168.1.0/24 network. However they need to 
ping and access the printers on the LAN(192.168.1.0/24) network from 
their 192.168.75.0/24 network.


That's where this all breaks down.  The guys at the far end are using 
SonicWall and want me to junk what we have and buy a much more 
expensive SonicWall(not to mention the subscription costs for 
filtering web access) to do what pfSense does now, using Squid and 
squidGuard.


The guys at the far end are claiming that our end is rejecting their 
ping packets from their server at 192.168.75.220.  I am unable to see 
any of their ping packets using pfSense's packet capture tool. I have 
played with 1:1 nat and tried every combo I can think of and have not 
come up with a working way to see their packets. I have googled and 
found several pfsense docs but am not able to come up with a working 
answer.


Just not even sure what  you guys need from me to help troubleshoot this.

Thanks in advance,
Lyle Giese
LCR Computer Services, Inc.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec nat issue

[Peder Rovelstad]

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?

I would think you would need another private net for the tunnel, something
like this:

http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike
-protocols/14143-same-ip.html


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec nat issue

[Mark Wiater]

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

Re: [pfSense] IPSec nat issue

[Vick Khera]

On Wed, May 25, 2016 at 8:54 PM, Lyle  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.
>

So if they have a conflicting 192.168.1.0/24 network on their end already,
how the heck do they expect traffic to *your* version of that network to
get routed to you? That is, if they type "ping 192.168.1.42" which network
is it supposed to go to? I don't see how some Sonicwall magic could make
that happen either.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] Strange fe80::1:1 link-local address on LAN interface

[Olivier Mascia]

By the way, this is on a pfSense/Netgate device and I still have at least 2 
support incidents available. I'd happily burn at least one of them to have 
someone remotely check this.

I'll be back on site within 2 hours from this post, I'll check the web by then 
for the proper procedure to open a case.

-- 
Meilleures salutations, Met vriendelijke groeten,  Best Regards,
Olivier Mascia (from mobile device), integral.be/om


> Le 26 mai 2016 à 13:03, Olivier Mascia  a écrit :
> 
> LAN Interface (lan, igb0)
> Statusup
> MAC Address00:08:a2:09:58:96
> IPv4 Address10.32.0.1
> Subnet mask IPv4255.255.0.0
> IPv6 Link Localfe80::1:1%igb0  (???)
> IPv6 Address2a02:578:4d07::1
> Subnet mask IPv664
> MTU1500
> Media1000baseT 
> 
> I do not understand where this fe80:1:1 comes from, it clearly isn't derived 
> from the MAC.
> 
> Indeed workstations on the LAN capture fe80::1:1 for their default gateway 
> and even pinging that IP from a workstation doesn't work:
> 
> ping6 fe80::1:1
> PING6(56=40+8+8 bytes) fe80::aa20:66ff:fe21:7c8e%en2 --> fe80::1:1
> ping6: sendmsg: No route to host
> ping6: wrote fe80::1:1 16 chars, ret=-1
> ping6: sendmsg: No route to host
> ping6: wrote fe80::1:1 16 chars, ret=-1
> 
> Not surprised.
> The question is where could this fe80::1:1 come from?
> So I could get rid of it and get there a proper link-local address?
> 
> Reboot does not help.
> Downloaded config file, there is no fe80::1:1 anywhere in there.
> 
> -- 
> Meilleures salutations, Met vriendelijke groeten, Best Regards,
> Olivier Mascia, integral.be/om
> 
> 
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

[pfSense] Strange fe80::1:1 link-local address on LAN interface

[Olivier Mascia]

LAN Interface (lan, igb0)
Status  up
MAC Address 00:08:a2:09:58:96
IPv4 Address10.32.0.1
Subnet mask IPv4255.255.0.0
IPv6 Link Local fe80::1:1%igb0  (???)
IPv6 Address2a02:578:4d07::1
Subnet mask IPv664
MTU 1500
Media   1000baseT 

I do not understand where this fe80:1:1 comes from, it clearly isn't derived 
from the MAC.

Indeed workstations on the LAN capture fe80::1:1 for their default gateway and 
even pinging that IP from a workstation doesn't work:

ping6 fe80::1:1
PING6(56=40+8+8 bytes) fe80::aa20:66ff:fe21:7c8e%en2 --> fe80::1:1
ping6: sendmsg: No route to host
ping6: wrote fe80::1:1 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote fe80::1:1 16 chars, ret=-1

Not surprised.
The question is where could this fe80::1:1 come from?
So I could get rid of it and get there a proper link-local address?

Reboot does not help.
Downloaded config file, there is no fe80::1:1 anywhere in there.

-- 
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold