Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - zen_spartan

Pages: [1]

19.7 Legacy Series / Re: IPsec Tunnels Routing Traffic Incorrectly

« on: August 01, 2019, 04:52:33 pm »

Changed to manual and it magically worked! thanks for your help

, odd thats its worked perfectly before update though.....

19.7 Legacy Series / Re: IPsec Tunnels Routing Traffic Incorrectly

« on: August 01, 2019, 04:25:02 pm »

How would you do that? Would you just have to take it out of hybrid mode to manual?
I dont see any settings within the IPsec setting section.

19.7 Legacy Series / Re: IPsec Tunnels Routing Traffic Incorrectly

« on: August 01, 2019, 02:50:45 pm »

screenshot attached

19.7 Legacy Series / Re: IPsec Tunnels Routing Traffic Incorrectly

« on: August 01, 2019, 01:57:52 pm »

Hopefully this will make things clearer:

Remote LAN Remote ipsec GW Local ipsec GW Local LAN

192.168.251.0/24 --->>> 10.1.6.2 =========IPsec Tunnel======== 10.1.6.1 <<<-----172.31.248.0/24

I have used a host on the Local LAN, IP 172.31.248.232, to ping a host on the Remote LAN, IP 192.168.251.1.
The ping fails.
The packet capture on the Local LAN interface of the opnsense router shows:

Quote

LAN
igb0   12:35:11.224685 aa:de:3d:a3:d8:c8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 26729, offset 0, flags [DF], proto ICMP (1), length 84)
172.31.248.232 > 192.168.251.1: ICMP echo request, id 56935, seq 1, length 64
172.31.248.232 > 192.168.251.1: ICMP echo request, id 56935, seq 2, length 64
172.31.248.232 > 192.168.251.1: ICMP echo request, id 56935, seq 3, length 64
172.31.248.232 > 192.168.251.1: ICMP echo request, id 56935, seq 4, length 64
172.31.248.232 > 192.168.251.1: ICMP echo request, id 56935, seq 5, length 64
172.31.248.232 > 192.168.251.1: ICMP echo request, id 56935, seq 6, length 64
LAN
igb0   12:35:12.246508 aa:de:3d:a3:d8:c8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 26983, offset 0, flags [DF], proto ICMP (1), length 84)
LAN
igb0   12:35:13.270404 aa:de:3d:a3:d8:c8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 27197, offset 0, flags [DF], proto ICMP (1), length 84)
LAN
igb0   12:35:14.294417 aa:de:3d:a3:d8:c8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 27374, offset 0, flags [DF], proto ICMP (1), length 84)
LAN
igb0   12:35:15.318361 aa:de:3d:a3:d8:c8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 27463, offset 0, flags [DF], proto ICMP (1), length 84)
LAN
igb0   12:35:16.319273 aa:de:3d:a3:d8:c8 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 27542, offset 0, flags [DF], proto ICMP (1), length 84)

The packet capture of the local IPsec Interface is:

Quote

ipsec3 Link
ipsec3000   12:37:20.926293 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 43556, offset 0, flags [DF], proto ICMP (1), length 84)
10.1.6.1 > 192.168.251.1: ICMP echo request, id 45508, seq 1, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 45508, seq 2, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 45508, seq 3, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 45508, seq 4, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 45508, seq 5, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 45508, seq 6, length 64
ipsec3 Link
ipsec3000   12:37:21.939754 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 43800, offset 0, flags [DF], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   12:37:22.963773 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 43827, offset 0, flags [DF], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   12:37:23.987734 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 43928, offset 0, flags [DF], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   12:37:25.011707 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 44092, offset 0, flags [DF], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   12:37:26.035754 AF IPv4 (2), length 88: (tos 0x0, ttl 63, id 44246, offset 0, flags [DF], proto ICMP (1), length 84)

does this make things clearer?

19.7 Legacy Series / Re: IPsec Tunnels Routing Traffic Incorrectly

« on: August 01, 2019, 12:24:43 pm »

I've carried out a ping test as before and carried out a packet capture at each end of the ipsec tunnel. however only the local capture, captured any data going to 192.168.251.1, this is shown below:

Quote

ipsec3 Link
ipsec3000   11:13:22.907227 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 11116, offset 0, flags [none], proto ICMP (1), length 84)
10.1.6.1 > 192.168.251.1: ICMP echo request, id 31059, seq 0, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 31059, seq 1, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 31059, seq 2, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 38881, seq 0, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 38881, seq 1, length 64
10.1.6.1 > 192.168.251.1: ICMP echo request, id 38881, seq 2, length 64
ipsec3 Link
ipsec3000   11:13:23.917966 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 25230, offset 0, flags [none], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   11:13:24.959863 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 33184, offset 0, flags [none], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   11:13:45.071377 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 51072, offset 0, flags [none], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   11:13:46.082154 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 25305, offset 0, flags [none], proto ICMP (1), length 84)
ipsec3 Link
ipsec3000   11:13:47.146092 AF IPv4 (2), length 88: (tos 0x0, ttl 64, id 46855, offset 0, flags [none], proto ICMP (1), length 84)

the ping gave the same error:

Quote

# /sbin/ping -S '172.31.248.2' -c '3' '192.168.251.1'
PING 192.168.251.1 (192.168.251.1) from 172.31.248.2: 56 data bytes

--- 192.168.251.1 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
ping: sendto: Permission denied
ping: sendto: Permission denied
ping: sendto: Permission denied

does this help?

19.7 Legacy Series / IPsec Tunnels Routing Traffic Incorrectly

« on: August 01, 2019, 09:24:15 am »

As requested a seperate thread...

We have 6 Ipsec tunnels, all not routing traffic correctly. Using 19.7.1, the traffic seems to being Nat’d on the given the tunnel interface. No blocks on the firewall.
Issues only began after upgrade to 19.7

When pinging from the opnsense LAN interface to a host on the remote end of the tunnel we get:

Quote

# /sbin/ping -S '172.31.248.3' -c '3' '192.168.251.1'
PING 192.168.251.1 (192.168.251.1) from 172.31.248.3: 56 data bytes

--- 192.168.251.1 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
ping: sendto: Permission denied
ping: sendto: Permission denied
ping: sendto: Permission denied

Any ideas?

many thanks

Zen

19.7 Legacy Series / Re: After upgrade to 19.7 routing over IPsec tunnels seems broken

« on: August 01, 2019, 09:17:45 am »

will do

17.1 Legacy Series / issue with netflow

« on: June 08, 2017, 11:33:25 am »

hi there,
trying to remote away netflow but keep getting this error in the log.....

configd.py: [e454efe0-ee67-4eca-a6c0-4868e4317d23] Inline action failed with OPNsense/Netflow OPNsense/Netflow/netflow.conf 'collections.OrderedDict object' has no attribute 'targets' at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 505, in execute return ph_inline_actions.execute(self, inline_act_parameters) File "/usr/local/opnsense/service/modules/ph_inline_actions.py", line 50, in execute filenames = tmpl.generate(parameters) File "/usr/local/opnsense/service/modules/template.py", line 309, in generate raise render_exception Exception: OPNsense/Netflow OPNsense/Netflow/netflow.conf 'collections.OrderedDict object' has no attribute 'targets'

just upgraded to OPNsense 17.1.8-amd64

any ideas?

many thanks

zen

Pages: [1]