Menu

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.

Show posts Menu

Messages - tamer

#1
Hi,

I couldn't find anything in the forum about this. I have set up unbound to only respond to certain network interfaces. I noticed that after setting up IPsec it is not listed with the other network interfaces which is the face under firewall rules. I suspect I just missed something simple.

As a workaround I tried to uncheck all interfaces (default for listening to all interfaces), but it didn't seem to work either.

In both cases I get (Wireshark):
DNS Flags: 0x8105 Standard query response, Refused

The only thing that seems to work is if I manually add the virtual IP addresses to the access list of unbound, however this is not the best solution if the virtual IPs change then one must remember to change them manually.

Tamer
#2
I'm getting the same kernel panic on ESXi 6.7 (https://forum.opnsense.org/index.php?topic=11419.0).
#3
19.1 Legacy Series / Kernel panic after upgrade
February 01, 2019, 09:51:22 PM
After updating to 19.1, rebooting will cause kernel panic:


Fatal trap 12: page fault while in kenl mode
cpuid = 0; apic id = 00
fault virtual address    = 0xd5
fault code               = supervisor read data, page not present
instruction pointer      = 0x20:0xffffffff80f3c7b0
stack pointer            = 0x20:0xffffffff8259e6b0
frame pointer            = 0x20:0xffffffff8259e7a0
code segment             = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres1, long 1, def32 0, gran 1
processor eflags         = interrupt enabled, resume, IOPL = 0
current process          = 0 ()
[ thread pid 0 tid 0 ]
Stopped at        vm_map_lookup+0x70:      cmpb     $0,0xd5(%rbx)


running bt:

Tracing pid 0 tid 0 td 0xffffffff8202d260
vm_map_lookup() at vm_map_lookup+0x70/frame 0xffffffff8259e7a0
vm_fault_hold() at vm_faulthold+0x66/frame 0xffffffff8259e8e0
vm_fault() at vm_faul+0x75/frame 0xffffffff8259ea920
trap_pfault() at trap_pfault+0x14c/frame 0xffffffff8259e980
trap() at trap+0x2c7/frame0xffffffff8259ea90
calltrap() at calltrap+0x8/frame 0xffffffff8259ea90
--- trap 0xc, rip = 0xffffffff80bc0896, rsp = 0xffffffff8259eb60, rbp = 0xffffffff8259eb70 ---
mi_startup() at mi_startup+0xc6/frame 0xffffffff8259eb70
btext() at btext+0x2c


I'm running in ESXi 6.7, this issue wasn't tested on 6.5 though. Other upgrades do not cause panic (tested 18.1->18.7).

Let me know if there is anything in particular I need to check. I have downgraded to 18.7.10_4 (using a snapshot) for now.

Edit: I forgot to mention that using kernel.old after upgrade boots without issue.
#4
Creating a gif tunnel (with TunnelBroker.net) the GUI does not create any way for firewall rules to be set specifically to the interface. The workaround that I am currently using is setting the rules that I need in the floating tab, but that is not as nice as having it in a separate tab like other interfaces. I suspect that this issues was not there in earlier releases (but I haven't tested with anything other than 17.1) as the wiki shows a tab for the created interface right away. I have also tried to remove and recreate the gif multiple times with several reboots, but it seems that the separate tab will not be created. I think this is a strictly a GUI issue as the firewall logs show blocks to certain IP as expected. Am I missing a step or did I forget to do something which makes the tab appear?
#5
General Discussion / Switching to Python 3?
September 14, 2016, 12:28:43 PM
Hi,

I was wondering whether it is planned or even wanted to ever switch to using Python 3 rather than 2.7? If there is any interest, I can help with the port efforts (but would need some pointers as to which parts are more important to port first). If I remember correctly, there are no scripts or code using Python in the base FreeBSD, which means there are only a few utilities (configd,...) that were added by opnsense this is make porting a bit easier.

Let me know if this is something that's wanted.

Tamer
#6
16.1 Legacy Series / Re: IDS/IPS DNS issues with LibreSSL
February 12, 2016, 07:23:44 PM
This is a non-issue I did not realise that after disabling hardware CRC checks I needed to reboot the router, it works as expected.
#7
After enabling LibreSSL and then trying to enable IDS/IPS with some rules the local (firewall) DNS resolver stops responding to any request even local host. However the issue might not be specific to the DNS resolvers as using dig with explicitly using another resolver still fails when IPS is enabled. On other hosts using an explicit DNS resolver works.

Firewall:
root@router:~ # dig google.com

; <<>> DiG 9.10.3-P3 <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached


root@router:~ # dig @8.8.8.8 google.com

; <<>> DiG 9.10.3-P3 <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached


Other hosts:
$ dig google.com

; <<>> DiG 9.8.3-P1 <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached


$ dig @8.8.8.8 google.com

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9677
;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.         IN   A

;; ANSWER SECTION:
google.com.      299   IN   A   93.62.101.241
google.com.      299   IN   A   93.62.101.207
google.com.      299   IN   A   93.62.101.222
google.com.      299   IN   A   93.62.101.211
google.com.      299   IN   A   93.62.101.251
google.com.      299   IN   A   93.62.101.245
google.com.      299   IN   A   93.62.101.236
google.com.      299   IN   A   93.62.101.230
google.com.      299   IN   A   93.62.101.249
google.com.      299   IN   A   93.62.101.237
google.com.      299   IN   A   93.62.101.215
google.com.      299   IN   A   93.62.101.221
google.com.      299   IN   A   93.62.101.219
google.com.      299   IN   A   93.62.101.226
google.com.      299   IN   A   93.62.101.234

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Feb  8 14:01:09 2016
;; MSG SIZE  rcvd: 268


I have tested this issue will 16.1-16.1.2.

(PS I don't think that that emoji should be interpreted  ;))
#8
16.1 Legacy Series / Re: IDS mode blocks all connections
February 08, 2016, 01:55:51 PM
Ok then mine is definitely another issue, thanks for the confirmation.
#9
(I'm not sure whether this is the correct place to post this, so please move it to the right board if it is not.)

I was wondering if you could add the possibility of choosing/setting the IPv4 of the interface that 6rd uses.

I ask because my external static IP is not the same as the IP that is assigned to my WAN interface. The one assigned to the WAN is a local IPv4 (eg 10.x.x.x) address, which cannot be used for 6rd. Through NAT I am able to set all of my outgoing traffic to use the correct public IPv4. My ISP does this as a way to protect their PBX server from external attacks as it remains internal to their network that can be access using the main WAS address but all other traffic should use the public address. A simple diagram of the situation:

+-----------+
|           | ----- 10.x.x.x (SIP traffic) -----------> ISP internal network
|    WAN    |
|           | ----- public_ip (everything else) ------> Internet
+-----------+


To be able to use my ISP 6rd deployment I need to generate a prefix corresponding to my external IP address rather than one corresponding to my internal one.

The easiest way I can see for this to be implemented is that an extra field could be added to the 5rd settings to set this IP address.

I have gave a quick look at the php file dealing with this but I wasn't able to pin it down to what exactly need to be changed. I someone could provide some pointers as to how this is best done, I can try to create a pull request for it.
#10
16.1 Legacy Series / Re: IDS mode blocks all connections
February 08, 2016, 01:25:25 PM
I'm not sure if this is related but enabling IDS/IPS on 16.1 (tested all up to 16.1.2) when LibreSSL is selected prevents the firewall from being able to use DNS for some reason. In my case however packets go through (if they are ok of course) as long as they are not DNS packets as those for some reason are dropped (ie ping works dig does not).

I was just wondering whether you're seeing this issue with LibreSSL only or with both? If both then likely my issue is different than yours.
#11
16.1 Legacy Series / Re: Outgoing NAT issue
January 31, 2016, 11:04:56 AM
Ok so upon further inspections I noticed that if I create an outgoing rule that matches any rather than specifically 127.0.0.0/8 it will use them for locally generated traffic. In my case this is sufficient, but for users with multiple public IPv4s it is slightly inconvenient to assign them to the hosts if one of the IPs is to be assigned to the router. This is still a regression in comparison to 15.7, but from my point of view it is no longer an issue. Sorry for the noise.
#12
16.1 Legacy Series / [SOLVED] Outgoing NAT issue
January 31, 2016, 06:31:07 AM
After installing a clean install of OPNsense 16.1 and without restoring config, I have notice a regression with respect to 15.7. If a manual outgoing NAT rule has been created for localhost (127.0.0.0/8) it will be ignored. I have noticed this issue by checking the IP used:

curl -vv http://ipinfo.io/ip


But I received a different one than the one I specified in the config. However, it is a bit odd as after checking the loaded pf rules I can see than this outgoing rule is there, but not satisfied.

Relevant pf rule:

nat on em0 inet from 127.0.0.0/8 to any -> <ext_ip> port 1024:65535 round-robin


I have also tried with the IP written manually rather than through an alias but got the same result. This behaviour persists even after a reboot, so it is not temporary issue (eg states).

This configuration worked for me with 15.7 (including all the development versions leading to 16.1). However, I'm not sure if the feature broke with just the latest commits or was there earlier with clean installs only (and as such didn't notice it).
#13
General Discussion / Re: Asterisk package/plugin
January 30, 2016, 02:33:25 PM
Wow! That's fast (even if it misses 16.1.1)!! Thank you very much!  ;D
#14
General Discussion / Re: Asterisk package/plugin
January 29, 2016, 10:19:55 PM
Hi Franco,

I think you might be onto something here; I suspect that there's a problem with the drive (it's not full though). I'm investigating this issue as the router just went down and isn't starting up again after seeing some DMA errors.

Regarding asterisk: it doesn't matter (the newer the better, easier to support?) I just need a SIP client/server. Having said that it isn't a deal breaker for me for whichever version you opt for (whether it's 1.8 or 12 or 13). I'll try the suggestions as soon as I can get the router back up.

Thanks for the great work on this project! ;D

Best,
Tamer
#15
General Discussion / Asterisk package/plugin
January 29, 2016, 04:16:31 PM
Hi,

I was wondering whether there is a pkg/plugin for asterisk (or any other SIP client for that matter).  I ask as I have a VoIP with my ISP but they block connections if they do not originate from the router that's connected to their network, which prevents me from using my phone. I have tried to compile asterisk on the router, but currently there's a problem in the automake pkg so I wasn't able to compile it.

Tamer

log of `pkg install automake`:

Updating OPNsense repository catalogue...
OPNsense repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (0 conflicting)
The following 5 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
automake: 1.15_1
automake-wrapper: 20131203
autoconf: 2.69
autoconf-wrapper: 20131203
m4: 1.4.17_1,1

The process will require 5 MiB more space.

Proceed with this action? [y/N]: y
[1/5] Installing autoconf-wrapper-20131203...
[1/5] Extracting autoconf-wrapper-20131203: 100%
[2/5] Installing m4-1.4.17_1,1...
[2/5] Extracting m4-1.4.17_1,1: 100%
[3/5] Installing automake-wrapper-20131203...
[3/5] Extracting automake-wrapper-20131203: 100%
[4/5] Installing autoconf-2.69...
[4/5] Extracting autoconf-2.69: 100%
[5/5] Installing automake-1.15_1...
[5/5] Extracting automake-1.15_1:  91%
pkg: archive_read_extract(): Can't create '/usr/local/share/automake-1.15/install-sh'
[5/5] Extracting automake-1.15_1: 100%
[5/5] Deleting files for automake-1.15_1: 100%