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 <roland@greentree.systems>
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
> <https://in.gtst.xyz/easyrule.php?action=block&int=ipsec&;
> src=41.75.111.178&ipproto=inet>
> 41.22.123.70:57914
> <https://in.gtst.xyz/easyrule.php?action=pass&int=ipsec&;
> proto=tcp&src=41.75.111.178&dst=196.201.107.67&dstport=21410&ipproto=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 <eero.voloti...@iki.fi> 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 <roland@greentree.systems
> >
> > wrote:
> >
> > > On 8 February 2018 at 20:40, Eero Volotinen <eero.voloti...@iki.fi>
> > 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" <roland@greentree.systems>
> 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
> > > > > <https://mailtrack.io/trace/link/3810b0b653bf2d2e2cba22508a65c8
> > > > <https://mailtrack.io/trace/link/892ace929998acda9ead81d80013db
> > > e1b7ad28cf?url=https%3A%2F%2Fmailtrack.io%2Ftrace%2Flink%
> > > 2F3810b0b653bf2d2e2cba22508a65c8&userId=977006&signature=
> > 9d738053b0d33cb5>
> > > > > ee1e61d53a?url=https%3A%2F%2Fin.gtst.xyz
> > > > <https://mailtrack.io/trace/link/f83ddb7327a8f200d411500bbce4cd
> > > 5593aa39f4?url=http%3A%2F%2F2Fin.gtst.xyz&userId=977006&
> > > signature=2a744f53ef768e7b>
> > > > %2Feasyrule.php%
> > > > > 3Faction%3Dblock%26int%3Dipsec%26src%3D41.75.111.178%
> > > > > 26ipproto%3Dinet&userId=977006&signature=20ffc7b51058b751>
> > > > > a.a.a.a:57914
> > > > > <https://mailtrack.io/trace/link/1a280d2835c7f522f38efd56201a0e
> > > > <https://mailtrack.io/trace/link/7695ee502d0c9ac5d0ed75c5577abe
> > > eec113a055?url=https%3A%2F%2Fmailtrack.io%2Ftrace%2Flink%
> > > 2F1a280d2835c7f522f38efd56201a0e&userId=977006&signature=
> > 571e99f7a2732a8f>
> > > > > b835d0bb60?url=https%3A%2F%2Fin.gtst.xyz
> > > > <https://mailtrack.io/trace/link/c2904059b91634be72796e03b8ffb1
> > > 4066c9777e?url=http%3A%2F%2F2Fin.gtst.xyz&userId=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&userId=
> > > > > 977006&signature=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
> > > > <https://mailtrack.io/trace/link/813c2da34aa99bf7f9eec9ae50b37e
> > > 3bd68e70ff?url=https%3A%2F%2Flists.pfsense.org%2Fmailman%
> > > 2Flistinfo%2Flist&userId=977006&signature=18f942cb3843942b>
> > > > > Support the project with Gold! https://pfsense.org/gold
> > > > <https://mailtrack.io/trace/link/460987973799abd5c29871361dc34f
> > > d4bf737bb0?url=https%3A%2F%2Fpfsense.org%2Fgold&userId=
> 977006&signature=
> > > 9b7e0fb022e1d4b3>
> > > > _______________________________________________
> > > > pfSense mailing list
> > > > https://lists.pfsense.org/mailman/listinfo/list
> > > > <https://mailtrack.io/trace/link/0552102ab27c30e6e81901e0c9ebf8
> > > bd42b5d7c3?url=https%3A%2F%2Flists.pfsense.org%2Fmailman%
> > > 2Flistinfo%2Flist&userId=977006&signature=cf850d54e37d5986>
> > > > Support the project with Gold! https://pfsense.org/gold
> > > > <https://mailtrack.io/trace/link/a64fb335799a74808cd4b40672ab63
> > > 34c841a087?url=https%3A%2F%2Fpfsense.org%2Fgold&userId=
> 977006&signature=
> > > 6f1a46c71565950f>
> > > _______________________________________________
> > > 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
>
_______________________________________________
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Reply via email to