OPNsense Forum

English Forums => General Discussion => Topic started by: Remington on January 27, 2020, 12:16:47 am

Title: Answer Packet is not passing PF but session counter increases
Post by: Remington on January 27, 2020, 12:16:47 am

I try to ping host 192.168.2.21 from 81.169.177.200

I see the echo-request (234) with tcpdump on the inboud interface. I see the request and response on the outbound interface.
The session table shows the same.  The inbound session shows 234 packets in and out, but the out session shows twice as packets for the out counter.

Code: [Select]

all icmp 192.168.2.21:3290 <- 81.169.177.200:3290       0:0
   age 00:03:54, expires in 00:00:09, 234:468 pkts, 19656:39312 bytes, rule 507
   id: 030000005e2df8c8 creatorid: 8368a371
all icmp 81.169.177.200:3290 -> 192.168.2.21:3290       0:0
   age 00:03:54, expires in 00:00:09, 234:234 pkts, 19656:19656 bytes, rule 127
   id: 030000005e2df8c9 creatorid: 8368a371
How can I find out why the echo-response is dropped?

Code: [Select]

@127 pass out log all flags S/SA keep state allow-opts label "fae559338f65e11c53669fc3642c93c2"
  [ Evaluations: 2132      Packets: 4173      Bytes: 1021132     States: 80    ]
  [ Inserted: uid 0 pid 82969 State Creations: 776   ]
@507 pass in log quick on wg0 reply-to (wg0 192.168.70.1) inet proto icmp from <schmu_srv03:4> to <wupp_schapp:3> keep state label "501718afceb1c0ed891df29dd33b09bf"
  [ Evaluations: 67        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 82969 State Creations: 0     ]


Title: Re: Answer Packet is not passing PF but session counter increases
Post by: marjohn56 on January 29, 2020, 08:34:59 am

Looks like a private rule block to me.


where are the two devices ? 192.168.2.21 is a private address 81.169.177.200 is not. Is one your LAN and the other the WAN?


You need to give more information.

Title: [Solved] Answer Packet is not passing PF but session counter increases
Post by: Remington on January 29, 2020, 05:43:24 pm

Sorry, I have missed a few parts to explain.


The packet from 81.169.177.200 is coming in via a Wireguard tunnel.
192.168.70.1 is the local ip of the wg0 interface.

I haven't used the routing from the WireGuard plugin, but created an dedicated gateway for this wg0 interfacee with 192.168.70.1 as gateway IP.
This was working well for traffic to the opposite direction. I was able to reach 81.169.177.200 from 192.168.2.21, but not the other way round as described above.

The wireguard interface on the far end has 192.168.70.2 as IP. This was only reachable, if I have configured a route for this IP to the local wg0 interface using the gateway 192.168.70.1

The solution was to change the destination IP for the wg0 interface from the local ip 192.168.70.1 to the IP of the fart end 192.168.70.2.

Now the traffic is passing regardless of the side it was initiated.
The only address I can't make reachable is 192.168.70.2, which doesn't hurt in my case.

Bye
  Thomas