Re: [pfSense] IPSec not routing traffic over tunnel

[Roland Giesler]

On 10 February 2018 at 11:11, Chris L  wrote:

>
> > On Feb 9, 2018, at 5:25 AM, Mark Wiater 
> wrote:
> >
> > In my experience, one does not see routes in the routing table for IPSEC
> based routes.
> >
> > IPSEC tunneling, I believe, happens before any NATting might. This might
> be why you're seeing your traffic exit the default gateway since it still
> possesses it's original ip addresses. I'm not sure what you are trying to
> achieve is possible on the same device, unless you do some kind of NAT on
> the incoming interface if that's possible.
> >
> > Seeing actual configuration files might be helpful. So would the results
> of packet capture on both I{SEC interfaces.
> >
>
> IPsec “routes” do not appear in the routing table. They are installed in
> the kernel as traffic selectors. Status > IPsec, SPDs.
>

h, I see them there now.


>
> If you are policy routing on the 192.168.110.130 interface you will need
> to bypass that with a pass rule to the other side (the Remote Network in
> the Phase 2) with no gateway set.
>

The pass rule, how do I set that with no gateway?


>
>
>
> ___
> 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 not routing traffic over tunnel

[Chris L]

> On Feb 9, 2018, at 5:25 AM, Mark Wiater  wrote:
> 
> 
> 
> On 2/9/2018 6:42 AM, Roland Giesler wrote:
>> Ok, I'll try again with real (fake) addresses to make it better understood.
>> 
>> WAN gateway: 197.212.127.194  (primary firewall interface), next hop
>> gateway 197.212.127.193
>> 
>> Phase1:
>> 
>> Interface: Virtual IP 41.22.123.70
>> 
>> Phase2:
>> 
>> Local address: address 192.168.110.130
>> Local NAT translation: address 41.22.123.70
>> 
>> Remote address: 196.210.117.67   (A public ip)
>> 
>> When phase1 and 2 are up and connected, I see no route for 196.210.117.67
>> in the routing table.
>> 
>> Doing a traceroute from 192.168.110.130, I get traffic leaving the network
>> via 197.212.127.193, not via 41.22.123.70.  This could be because
>> 41.22.123.70 is just a virtual address though, or what?  It may not be
>> meaningful after all.
>> 
>> In the firewall log I see:
>> Feb 8 18:07:40 â–º IPsec
>> 
>> 41.22.123.70:57914
>> 
>> 196.210.117.67:12345 TCP:S
>> So traffic is being allowed via IPsec from 41.22.123.70 to 196.210.117.67,
>> but I'm not getting any response from the remote.
>> 
>> Is this wrong?  If so, what is right?  I cannot expose the LAN ip address
>> to the tunnel (192.168.110.130), I need to use the public IP...
>> 
>> thanks again
>> 
>> 
> 
> In my experience, one does not see routes in the routing table for IPSEC 
> based routes.
> 
> IPSEC tunneling, I believe, happens before any NATting might. This might be 
> why you're seeing your traffic exit the default gateway since it still 
> possesses it's original ip addresses. I'm not sure what you are trying to 
> achieve is possible on the same device, unless you do some kind of NAT on the 
> incoming interface if that's possible.
> 
> Seeing actual configuration files might be helpful. So would the results of 
> packet capture on both I{SEC interfaces.
> 
> 

IPsec “routes” do not appear in the routing table. They are installed in the 
kernel as traffic selectors. Status > IPsec, SPDs.

If you are policy routing on the 192.168.110.130 interface you will need to 
bypass that with a pass rule to the other side (the Remote Network in the Phase 
2) with no gateway set.



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

Re: [pfSense] IPSec not routing traffic over tunnel

[Roland Giesler]

The issue has been resolved.  I was using ip addresses that were in my list
of virtual ip addresses as well.  After removing them from the virtual list
it works like a charm!


On 9 February 2018 at 15:25, Mark Wiater  wrote:

>
>
> On 2/9/2018 6:42 AM, Roland Giesler wrote:
>
>> Ok, I'll try again with real (fake) addresses to make it better
>> understood.
>>
>> WAN gateway: 197.212.127.194  (primary firewall interface), next hop
>> gateway 197.212.127.193
>>
>> Phase1:
>>
>> Interface: Virtual IP 41.22.123.70
>>
>> Phase2:
>>
>> Local address: address 192.168.110.130
>> Local NAT translation: address 41.22.123.70
>>
>> Remote address: 196.210.117.67   (A public ip)
>>
>> When phase1 and 2 are up and connected, I see no route for 196.210.117.67
>> in the routing table.
>>
>> Doing a traceroute from 192.168.110.130, I get traffic leaving the network
>> via 197.212.127.193, not via 41.22.123.70.  This could be because
>> 41.22.123.70 is just a virtual address though, or what?  It may not be
>> meaningful after all.
>>
>> In the firewall log I see:
>> Feb 8 18:07:40 â–º IPsec
>> > =41.75.111.178=inet
>> 
>> >
>> 41.22.123.70:57914
>> 
>> > o=tcp=41.75.111.178=196.201.107.67=21410=inet
>> 
>> >
>> 196.210.117.67:12345
>> 
>> TCP:S
>> So traffic is being allowed via IPsec from 41.22.123.70 to 196.210.117.67,
>> but I'm not getting any response from the remote.
>>
>> Is this wrong?  If so, what is right?  I cannot expose the LAN ip address
>> to the tunnel (192.168.110.130), I need to use the public IP...
>>
>> thanks again
>>
>>
>>
> In my experience, one does not see routes in the routing table for IPSEC
> based routes.
>
> IPSEC tunneling, I believe, happens before any NATting might. This might
> be why you're seeing your traffic exit the default gateway since it still
> possesses it's original ip addresses. I'm not sure what you are trying to
> achieve is possible on the same device, unless you do some kind of NAT on
> the incoming interface if that's possible.
>
> Seeing actual configuration files might be helpful. So would the results
> of packet capture on both I{SEC interfaces.
>
> Mark
>
> ___
> 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 not routing traffic over tunnel

[Mark Wiater]

On 2/9/2018 6:42 AM, Roland Giesler wrote:

Ok, I'll try again with real (fake) addresses to make it better understood.

WAN gateway: 197.212.127.194  (primary firewall interface), next hop
gateway 197.212.127.193

Phase1:

Interface: Virtual IP 41.22.123.70

Phase2:

Local address: address 192.168.110.130
Local NAT translation: address 41.22.123.70

Remote address: 196.210.117.67   (A public ip)

When phase1 and 2 are up and connected, I see no route for 196.210.117.67
in the routing table.

Doing a traceroute from 192.168.110.130, I get traffic leaving the network
via 197.212.127.193, not via 41.22.123.70.  This could be because
41.22.123.70 is just a virtual address though, or what?  It may not be
meaningful after all.

In the firewall log I see:
Feb 8 18:07:40 â–º IPsec

41.22.123.70:57914

196.210.117.67:12345 TCP:S
So traffic is being allowed via IPsec from 41.22.123.70 to 196.210.117.67,
but I'm not getting any response from the remote.

Is this wrong?  If so, what is right?  I cannot expose the LAN ip address
to the tunnel (192.168.110.130), I need to use the public IP...

thanks again




In my experience, one does not see routes in the routing table for IPSEC based 
routes.

IPSEC tunneling, I believe, happens before any NATting might. This might be why 
you're seeing your traffic exit the default gateway since it still possesses 
it's original ip addresses. I'm not sure what you are trying to achieve is 
possible on the same device, unless you do some kind of NAT on the incoming 
interface if that's possible.

Seeing actual configuration files might be helpful. So would the results of 
packet capture on both I{SEC interfaces.

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

Re: [pfSense] IPSec not routing traffic over tunnel

[Eero Volotinen]

 I am sorry, but I cannot help.

You can get commercial support from NetGate.

--
Eero

On Fri, Feb 9, 2018 at 1:42 PM, Roland Giesler 
wrote:

> Ok, I'll try again with real (fake) addresses to make it better understood.
>
> WAN gateway: 197.212.127.194  (primary firewall interface), next hop
> gateway 197.212.127.193
>
> Phase1:
>
> Interface: Virtual IP 41.22.123.70
>
> Phase2:
>
> Local address: address 192.168.110.130
> Local NAT translation: address 41.22.123.70
>
> Remote address: 196.210.117.67   (A public ip)
>
> When phase1 and 2 are up and connected, I see no route for 196.210.117.67
> in the routing table.
>
> Doing a traceroute from 192.168.110.130, I get traffic leaving the network
> via 197.212.127.193, not via 41.22.123.70.  This could be because
> 41.22.123.70 is just a virtual address though, or what?  It may not be
> meaningful after all.
>
> In the firewall log I see:
> Feb 8 18:07:40 ► IPsec
>  src=41.75.111.178=inet>
> 41.22.123.70:57914
>  proto=tcp=41.75.111.178=196.201.107.67=21410=inet>
> 196.210.117.67:12345 TCP:S
> So traffic is being allowed via IPsec from 41.22.123.70 to 196.210.117.67,
> but I'm not getting any response from the remote.
>
> Is this wrong?  If so, what is right?  I cannot expose the LAN ip address
> to the tunnel (192.168.110.130), I need to use the public IP...
>
> thanks again
>
>
> On 8 February 2018 at 23:51, Eero Volotinen  wrote:
>
> > Well. Maybe You need to hire pfsense consultant with NDA, so you can
> unmask
> > needed information.
> >
> > Usually there is no need to NAT in ipsec as you can tunnel private
> > network/ip address too and limit access with firewall rules.
> >
> > Eero
> >
> > On Thu, Feb 8, 2018 at 9:42 PM, Roland Giesler  >
> > wrote:
> >
> > > On 8 February 2018 at 20:40, Eero Volotinen 
> > wrote:
> > >
> > > > how about not masking ip addresses?
> > > >
> > >
> > > I'm not allowed to show the ip addresses (by my client), hence the
> > > masking...
> > >
> > > I thought I need NAT, but I also testing simply added the virtual ip,
> > > a.a.a.a as the address, but it still doesn't work.
> > >
> > >
> > >
> > > >
> > > > do you really need nat in phase 2 ? why?
> > > >
> > >
> > > I have servers in a farm all NAT'ed (ie they only have LAN addresses)
> and
> > > use NAT to forward the desired traffic to them (ie HTTPS to a web
> > server).
> > >
> > > Now, it I want to establish an IPSec link that will allow a service
> > > provider to push API calls to our server (with the NAT'ed address), I
> > want
> > > to give them a public address to talk to and them NAT that traffic to
> the
> > > actual server.  I understood that's the point of having NAT as an
> option
> > in
> > > phase2?
> > >
> > > I don't see any other way to achieve that, not?
> > >
> > >
> > >
> > > >
> > > > Eero
> > > >
> > > >
> > > >
> > > > 8.2.2018 18.17 "Roland Giesler" 
> kirjoitti:
> > > >
> > > > > I'm trying to find a solution and know there are quite a few
> pfSense
> > > > users
> > > > > here, so here goes...
> > > > >
> > > > > We've set up some IPSec tunnels and they connect.  The Phase2 also
> > > "comes
> > > > > up", but we can't reach the hosts specified in the Phase2 "remote
> > > > network".
> > > > >
> > > > > One instance (to keep it simpler):
> > > > >
> > > > > WAN gateway: x.x.x.x  (primary firewall interface)
> > > > >
> > > > > Phase1:
> > > > >
> > > > > Interface: Virtual IP a.a.a.a
> > > > >
> > > > > Phase2:
> > > > >
> > > > > Local address: address c.c.c.c
> > > > > Local NAT translation: address a.a.a.a
> > > > >
> > > > > Remote address: r.r.r.r  (A public ip)
> > > > >
> > > > > When phase1 and 2 are up and connected, I see no route for r.r.r.r
> in
> > > the
> > > > > routing table.
> > > > >
> > > > > Doing a traceroute from c.c.c.c, I get traffic leaving the network
> > via
> > > > > x.x.x.x, not via a.a.a.a.  This could be because x.x.x.x is just a
> > > > virtual
> > > > > address though, or what?
> > > > >
> > > > > In the firewall log I see:
> > > > > Feb 8 18:07:40 ► IPsec
> > > > >  > > >  > > e1b7ad28cf?url=https%3A%2F%2Fmailtrack.io%2Ftrace%2Flink%
> > > 2F3810b0b653bf2d2e2cba22508a65c8=977006=
> > 9d738053b0d33cb5>
> > > > > ee1e61d53a?url=https%3A%2F%2Fin.gtst.xyz
> > > >  > > 5593aa39f4?url=http%3A%2F%2F2Fin.gtst.xyz=977006&
> > > signature=2a744f53ef768e7b>
> > > > %2Feasyrule.php%
> > > > > 3Faction%3Dblock%26int%3Dipsec%26src%3D41.75.111.178%
> > > > > 26ipproto%3Dinet=977006=20ffc7b51058b751>
> > > > > a.a.a.a:57914
> > > > >  > > > 

Re: [pfSense] IPSec not routing traffic over tunnel

[Roland Giesler]

Ok, I'll try again with real (fake) addresses to make it better understood.

WAN gateway: 197.212.127.194  (primary firewall interface), next hop
gateway 197.212.127.193

Phase1:

Interface: Virtual IP 41.22.123.70

Phase2:

Local address: address 192.168.110.130
Local NAT translation: address 41.22.123.70

Remote address: 196.210.117.67   (A public ip)

When phase1 and 2 are up and connected, I see no route for 196.210.117.67
in the routing table.

Doing a traceroute from 192.168.110.130, I get traffic leaving the network
via 197.212.127.193, not via 41.22.123.70.  This could be because
41.22.123.70 is just a virtual address though, or what?  It may not be
meaningful after all.

In the firewall log I see:
Feb 8 18:07:40 ► IPsec

41.22.123.70:57914

196.210.117.67:12345 TCP:S
So traffic is being allowed via IPsec from 41.22.123.70 to 196.210.117.67,
but I'm not getting any response from the remote.

Is this wrong?  If so, what is right?  I cannot expose the LAN ip address
to the tunnel (192.168.110.130), I need to use the public IP...

thanks again


On 8 February 2018 at 23:51, Eero Volotinen  wrote:

> Well. Maybe You need to hire pfsense consultant with NDA, so you can unmask
> needed information.
>
> Usually there is no need to NAT in ipsec as you can tunnel private
> network/ip address too and limit access with firewall rules.
>
> Eero
>
> On Thu, Feb 8, 2018 at 9:42 PM, Roland Giesler 
> wrote:
>
> > On 8 February 2018 at 20:40, Eero Volotinen 
> wrote:
> >
> > > how about not masking ip addresses?
> > >
> >
> > I'm not allowed to show the ip addresses (by my client), hence the
> > masking...
> >
> > I thought I need NAT, but I also testing simply added the virtual ip,
> > a.a.a.a as the address, but it still doesn't work.
> >
> >
> >
> > >
> > > do you really need nat in phase 2 ? why?
> > >
> >
> > I have servers in a farm all NAT'ed (ie they only have LAN addresses) and
> > use NAT to forward the desired traffic to them (ie HTTPS to a web
> server).
> >
> > Now, it I want to establish an IPSec link that will allow a service
> > provider to push API calls to our server (with the NAT'ed address), I
> want
> > to give them a public address to talk to and them NAT that traffic to the
> > actual server.  I understood that's the point of having NAT as an option
> in
> > phase2?
> >
> > I don't see any other way to achieve that, not?
> >
> >
> >
> > >
> > > Eero
> > >
> > >
> > >
> > > 8.2.2018 18.17 "Roland Giesler"  kirjoitti:
> > >
> > > > I'm trying to find a solution and know there are quite a few pfSense
> > > users
> > > > here, so here goes...
> > > >
> > > > We've set up some IPSec tunnels and they connect.  The Phase2 also
> > "comes
> > > > up", but we can't reach the hosts specified in the Phase2 "remote
> > > network".
> > > >
> > > > One instance (to keep it simpler):
> > > >
> > > > WAN gateway: x.x.x.x  (primary firewall interface)
> > > >
> > > > Phase1:
> > > >
> > > > Interface: Virtual IP a.a.a.a
> > > >
> > > > Phase2:
> > > >
> > > > Local address: address c.c.c.c
> > > > Local NAT translation: address a.a.a.a
> > > >
> > > > Remote address: r.r.r.r  (A public ip)
> > > >
> > > > When phase1 and 2 are up and connected, I see no route for r.r.r.r in
> > the
> > > > routing table.
> > > >
> > > > Doing a traceroute from c.c.c.c, I get traffic leaving the network
> via
> > > > x.x.x.x, not via a.a.a.a.  This could be because x.x.x.x is just a
> > > virtual
> > > > address though, or what?
> > > >
> > > > In the firewall log I see:
> > > > Feb 8 18:07:40 ► IPsec
> > > >  > >  > e1b7ad28cf?url=https%3A%2F%2Fmailtrack.io%2Ftrace%2Flink%
> > 2F3810b0b653bf2d2e2cba22508a65c8=977006=
> 9d738053b0d33cb5>
> > > > ee1e61d53a?url=https%3A%2F%2Fin.gtst.xyz
> > >  > 5593aa39f4?url=http%3A%2F%2F2Fin.gtst.xyz=977006&
> > signature=2a744f53ef768e7b>
> > > %2Feasyrule.php%
> > > > 3Faction%3Dblock%26int%3Dipsec%26src%3D41.75.111.178%
> > > > 26ipproto%3Dinet=977006=20ffc7b51058b751>
> > > > a.a.a.a:57914
> > > >  > >  > eec113a055?url=https%3A%2F%2Fmailtrack.io%2Ftrace%2Flink%
> > 2F1a280d2835c7f522f38efd56201a0e=977006=
> 571e99f7a2732a8f>
> > > > b835d0bb60?url=https%3A%2F%2Fin.gtst.xyz
> > >  > 4066c9777e?url=http%3A%2F%2F2Fin.gtst.xyz=977006&
> > signature=cdc956157cdd5df3>
> > > %2Feasyrule.php%
> > > > 

Re: [pfSense] IPSec not routing traffic over tunnel

[Eero Volotinen]

Well. Maybe You need to hire pfsense consultant with NDA, so you can unmask
needed information.

Usually there is no need to NAT in ipsec as you can tunnel private
network/ip address too and limit access with firewall rules.

Eero

On Thu, Feb 8, 2018 at 9:42 PM, Roland Giesler 
wrote:

> On 8 February 2018 at 20:40, Eero Volotinen  wrote:
>
> > how about not masking ip addresses?
> >
>
> I'm not allowed to show the ip addresses (by my client), hence the
> masking...
>
> I thought I need NAT, but I also testing simply added the virtual ip,
> a.a.a.a as the address, but it still doesn't work.
>
>
>
> >
> > do you really need nat in phase 2 ? why?
> >
>
> I have servers in a farm all NAT'ed (ie they only have LAN addresses) and
> use NAT to forward the desired traffic to them (ie HTTPS to a web server).
>
> Now, it I want to establish an IPSec link that will allow a service
> provider to push API calls to our server (with the NAT'ed address), I want
> to give them a public address to talk to and them NAT that traffic to the
> actual server.  I understood that's the point of having NAT as an option in
> phase2?
>
> I don't see any other way to achieve that, not?
>
>
>
> >
> > Eero
> >
> >
> >
> > 8.2.2018 18.17 "Roland Giesler"  kirjoitti:
> >
> > > I'm trying to find a solution and know there are quite a few pfSense
> > users
> > > here, so here goes...
> > >
> > > We've set up some IPSec tunnels and they connect.  The Phase2 also
> "comes
> > > up", but we can't reach the hosts specified in the Phase2 "remote
> > network".
> > >
> > > One instance (to keep it simpler):
> > >
> > > WAN gateway: x.x.x.x  (primary firewall interface)
> > >
> > > Phase1:
> > >
> > > Interface: Virtual IP a.a.a.a
> > >
> > > Phase2:
> > >
> > > Local address: address c.c.c.c
> > > Local NAT translation: address a.a.a.a
> > >
> > > Remote address: r.r.r.r  (A public ip)
> > >
> > > When phase1 and 2 are up and connected, I see no route for r.r.r.r in
> the
> > > routing table.
> > >
> > > Doing a traceroute from c.c.c.c, I get traffic leaving the network via
> > > x.x.x.x, not via a.a.a.a.  This could be because x.x.x.x is just a
> > virtual
> > > address though, or what?
> > >
> > > In the firewall log I see:
> > > Feb 8 18:07:40 ► IPsec
> > >  >  e1b7ad28cf?url=https%3A%2F%2Fmailtrack.io%2Ftrace%2Flink%
> 2F3810b0b653bf2d2e2cba22508a65c8=977006=9d738053b0d33cb5>
> > > ee1e61d53a?url=https%3A%2F%2Fin.gtst.xyz
> >  5593aa39f4?url=http%3A%2F%2F2Fin.gtst.xyz=977006&
> signature=2a744f53ef768e7b>
> > %2Feasyrule.php%
> > > 3Faction%3Dblock%26int%3Dipsec%26src%3D41.75.111.178%
> > > 26ipproto%3Dinet=977006=20ffc7b51058b751>
> > > a.a.a.a:57914
> > >  >  eec113a055?url=https%3A%2F%2Fmailtrack.io%2Ftrace%2Flink%
> 2F1a280d2835c7f522f38efd56201a0e=977006=571e99f7a2732a8f>
> > > b835d0bb60?url=https%3A%2F%2Fin.gtst.xyz
> >  4066c9777e?url=http%3A%2F%2F2Fin.gtst.xyz=977006&
> signature=cdc956157cdd5df3>
> > %2Feasyrule.php%
> > > 3Faction%3Dpass%26int%3Dipsec%26proto%3Dtcp%26src%3D41.75.
> > > 111.178%26dst%3D196.201.107.67%26dstport%3D21410%
> > 26ipproto%3Dinet=
> > > 977006=9606a76d3910d126>
> > > r.r.r.r:12345 TCP:S
> > > So traffic is being allowed via IPsec from a.a.a.a to r.r.r.r, but I'm
> > not
> > > getting any response from the remote.
> > >
> > > What is going on here?  Should there be a route to r.r.r.r in the
> routing
> > > table or does pfSense hide some mechanics of the ports and routes from
> > me?
> > >
> > > Thanks
> > >
> > > Roland
> > > ___
> > > pfSense mailing list
> > > https://lists.pfsense.org/mailman/listinfo/list
> >  3bd68e70ff?url=https%3A%2F%2Flists.pfsense.org%2Fmailman%
> 2Flistinfo%2Flist=977006=18f942cb3843942b>
> > > Support the project with Gold! https://pfsense.org/gold
> >  d4bf737bb0?url=https%3A%2F%2Fpfsense.org%2Fgold=977006=
> 9b7e0fb022e1d4b3>
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> >  bd42b5d7c3?url=https%3A%2F%2Flists.pfsense.org%2Fmailman%
> 2Flistinfo%2Flist=977006=cf850d54e37d5986>
> > Support the project with Gold! https://pfsense.org/gold
> >  34c841a087?url=https%3A%2F%2Fpfsense.org%2Fgold=977006=
> 6f1a46c71565950f>
> 

Re: [pfSense] IPSec not routing traffic over tunnel

[Roland Giesler]

On 8 February 2018 at 20:40, Eero Volotinen  wrote:

> how about not masking ip addresses?
>

I'm not allowed to show the ip addresses (by my client), hence the
masking...

I thought I need NAT, but I also testing simply added the virtual ip,
a.a.a.a as the address, but it still doesn't work.



>
> do you really need nat in phase 2 ? why?
>

I have servers in a farm all NAT'ed (ie they only have LAN addresses) and
use NAT to forward the desired traffic to them (ie HTTPS to a web server).

Now, it I want to establish an IPSec link that will allow a service
provider to push API calls to our server (with the NAT'ed address), I want
to give them a public address to talk to and them NAT that traffic to the
actual server.  I understood that's the point of having NAT as an option in
phase2?

I don't see any other way to achieve that, not?



>
> Eero
>
>
>
> 8.2.2018 18.17 "Roland Giesler"  kirjoitti:
>
> > I'm trying to find a solution and know there are quite a few pfSense
> users
> > here, so here goes...
> >
> > We've set up some IPSec tunnels and they connect.  The Phase2 also "comes
> > up", but we can't reach the hosts specified in the Phase2 "remote
> network".
> >
> > One instance (to keep it simpler):
> >
> > WAN gateway: x.x.x.x  (primary firewall interface)
> >
> > Phase1:
> >
> > Interface: Virtual IP a.a.a.a
> >
> > Phase2:
> >
> > Local address: address c.c.c.c
> > Local NAT translation: address a.a.a.a
> >
> > Remote address: r.r.r.r  (A public ip)
> >
> > When phase1 and 2 are up and connected, I see no route for r.r.r.r in the
> > routing table.
> >
> > Doing a traceroute from c.c.c.c, I get traffic leaving the network via
> > x.x.x.x, not via a.a.a.a.  This could be because x.x.x.x is just a
> virtual
> > address though, or what?
> >
> > In the firewall log I see:
> > Feb 8 18:07:40 ► IPsec
> >  
> > ee1e61d53a?url=https%3A%2F%2Fin.gtst.xyz
> 
> %2Feasyrule.php%
> > 3Faction%3Dblock%26int%3Dipsec%26src%3D41.75.111.178%
> > 26ipproto%3Dinet=977006=20ffc7b51058b751>
> > a.a.a.a:57914
> >  
> > b835d0bb60?url=https%3A%2F%2Fin.gtst.xyz
> 
> %2Feasyrule.php%
> > 3Faction%3Dpass%26int%3Dipsec%26proto%3Dtcp%26src%3D41.75.
> > 111.178%26dst%3D196.201.107.67%26dstport%3D21410%
> 26ipproto%3Dinet=
> > 977006=9606a76d3910d126>
> > r.r.r.r:12345 TCP:S
> > So traffic is being allowed via IPsec from a.a.a.a to r.r.r.r, but I'm
> not
> > getting any response from the remote.
> >
> > What is going on here?  Should there be a route to r.r.r.r in the routing
> > table or does pfSense hide some mechanics of the ports and routes from
> me?
> >
> > Thanks
> >
> > Roland
> > ___
> > 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 mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPSec not routing traffic over tunnel

[Eero Volotinen]

how about not masking ip addresses?

do you really need nat in phase 2 ? why?

Eero



8.2.2018 18.17 "Roland Giesler"  kirjoitti:

> I'm trying to find a solution and know there are quite a few pfSense users
> here, so here goes...
>
> We've set up some IPSec tunnels and they connect.  The Phase2 also "comes
> up", but we can't reach the hosts specified in the Phase2 "remote network".
>
> One instance (to keep it simpler):
>
> WAN gateway: x.x.x.x  (primary firewall interface)
>
> Phase1:
>
> Interface: Virtual IP a.a.a.a
>
> Phase2:
>
> Local address: address c.c.c.c
> Local NAT translation: address a.a.a.a
>
> Remote address: r.r.r.r  (A public ip)
>
> When phase1 and 2 are up and connected, I see no route for r.r.r.r in the
> routing table.
>
> Doing a traceroute from c.c.c.c, I get traffic leaving the network via
> x.x.x.x, not via a.a.a.a.  This could be because x.x.x.x is just a virtual
> address though, or what?
>
> In the firewall log I see:
> Feb 8 18:07:40 ► IPsec
>  ee1e61d53a?url=https%3A%2F%2Fin.gtst.xyz%2Feasyrule.php%
> 3Faction%3Dblock%26int%3Dipsec%26src%3D41.75.111.178%
> 26ipproto%3Dinet=977006=20ffc7b51058b751>
> a.a.a.a:57914
>  b835d0bb60?url=https%3A%2F%2Fin.gtst.xyz%2Feasyrule.php%
> 3Faction%3Dpass%26int%3Dipsec%26proto%3Dtcp%26src%3D41.75.
> 111.178%26dst%3D196.201.107.67%26dstport%3D21410%26ipproto%3Dinet=
> 977006=9606a76d3910d126>
> r.r.r.r:12345 TCP:S
> So traffic is being allowed via IPsec from a.a.a.a to r.r.r.r, but I'm not
> getting any response from the remote.
>
> What is going on here?  Should there be a route to r.r.r.r in the routing
> table or does pfSense hide some mechanics of the ports and routes from me?
>
> Thanks
>
> Roland
> ___
> 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] IPSec not routing traffic over tunnel

[Roland Giesler]

I'm trying to find a solution and know there are quite a few pfSense users
here, so here goes...

We've set up some IPSec tunnels and they connect.  The Phase2 also "comes
up", but we can't reach the hosts specified in the Phase2 "remote network".

One instance (to keep it simpler):

WAN gateway: x.x.x.x  (primary firewall interface)

Phase1:

Interface: Virtual IP a.a.a.a

Phase2:

Local address: address c.c.c.c
Local NAT translation: address a.a.a.a

Remote address: r.r.r.r  (A public ip)

When phase1 and 2 are up and connected, I see no route for r.r.r.r in the
routing table.

Doing a traceroute from c.c.c.c, I get traffic leaving the network via
x.x.x.x, not via a.a.a.a.  This could be because x.x.x.x is just a virtual
address though, or what?

In the firewall log I see:
Feb 8 18:07:40 ► IPsec

a.a.a.a:57914

r.r.r.r:12345 TCP:S
So traffic is being allowed via IPsec from a.a.a.a to r.r.r.r, but I'm not
getting any response from the remote.

What is going on here?  Should there be a route to r.r.r.r in the routing
table or does pfSense hide some mechanics of the ports and routes from me?

Thanks

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